DDD
ドメイン駆動設計

ちょっとずつ読むドメイン駆動設計 第一部 ドメインモデルを機能させる 第三章 モデルと実装を結びつける5

実践的モデラ

ソフトウェア開発は、すべてが設計なのだ。

これがすべて。

なぜかということをエヴァンス本人の体験を元に書かれていました。

プロジェクトは、エヴァンスがモデラとして加入するものの、実装は別部隊がしていたというもの。
結果、モデルは利用されることがなかったといいます。理由は2つ。

  • モデルがもたらす全体的な効果は、詳細の影響を非常に受けやすい(第一部 第三章より)
  • モデルが実装や技術と相互作用したことで生じるフィードバックを、直接得られなかった(第一部 第三章より)

モデルを実装するとき、詳細を実装するに従って、モデルも変更する必要が出てきた経験は何度もあります。というか、毎回そうですね。
そもそも、モデルを作成したら、そのまま詳細を実装できるようなら「モデル駆動設計」で言っていたような反復をする必要はないですよね。

だから、

  • コードを作成する人々がモデルに責任を持つ
  • アプリケーションのためにモデルを機能させる方法を理解する
  • コードを変更するとモデルも変わることを、開発者が認識する
  • モデラも実装する
  • プログラマはモデラでもある
  • すべての開発者は、モデルに関する議論にいずれかの段階で参加して、ドメインエキスパートと話をしなければならない

ということを意識しなければいけませんね。

モデラも実装する必要があり、プログラマもモデラであるなら、プログラマとモデラを厳密に分けてはいけないとうことがわかります。

モデルと実装は分けられないので、モデラとプログラマも厳密には分けられない。