【Eric Evans DDD】読書メモ 2 第3章 モデルと実装を結びつける

第3章 モデルと実装を結びつける

モデル駆動設計(MODEL-DRIVEN DESIGN)

モデルがコードとの結びつきが薄くなってくると、最初の調査には役立つかもしれないが、徐々に的外れなものになり、誤解を招くようになる。しかし意図的にこの結びつきを断ち切る場合もある。

• 分析モデル・・・ビジネスドメインを理解するためだけに使われ実際の実装と混ぜて考えてしまうとわかりにくい。設計の問題に留意しないまま作成されるので、設計の際に求められることに対して全く合わない可能性が高く、開発が始まると設計のための新しい抽象を考え出さなければならず、アナリストによってmドエルに組み込まれた洞察が維持され再発見される保証は全くないので費用対効果が低い。

• 設計、設計の中心となる部分がドメインモデルに結びついていなければ、そのモデルにはほとんど価値はなく、ソフトウェアが正確かどうかも怪しい。同じように、モデルと設計された機能との紐付けが複雑だと理解するのが難しく、実際には設計が変更された時に紐付けを維持できなくなる。

分析・・・ドメインから得られる基本的な概念をわかりやすく表現力豊かな方法で捉える
設計・・・コンポーネントの集合を定義しなければならない.コンポーネントはプロジェクトで使用されるプログラミングツールを使って構築できて、デプロイ先の環境で効率的に実行され、アプリケーションに課せられた問題を正しく解決できなければならない。

• モデル駆動設計では分析としても設計としてもうまく機能するモデルを要求する。
• モデルが実装にとって実用的でないと思われる場合も、モデルがドメインの主要な概念を忠実に表現していない場合も、新しいモデルを探さなければならない。
• ソフトウェアの一部を設計する際には紐付けが明らかになるようにドメインモデルを文字通りの意味で忠実に反映させること。これはドメインに対する深い洞察を反映させようとする時にも言える。強固なユビキタス言語を支えることに加えて、ドメインと実装両方の目的に使える単一のモデルを要求すること。
• 設計で使用する用語法と責務の基本的な割り当てをモデルから引き出すこと。コードはモデルの表現となるから、コードに対する変更になるかもしれない。その影響はプロジェクトの他の活動全体へと適宜伝わっていかなければならない。
• 実装を一部の狂いもなくモデルみ結びつけるには、通常、オブジェクト指向プログラミングのようなモデリングパラダイムをサポートする、ソフトウェア開発のためのツールと言語が必要である。

モデリングパラダイムとルールによるサポート

モデルと設計を厳密に一致させるためにほぼ必須となるのは、作業に用いるモデリングパラダイムが、モデルに含まれる概念と直接的に類似したものを生成できるソフトウェアによってサポートされているということ。

• オブジェクト指向プログラミングが強力なのは、あるプログラミングパラダイムに基づいていて、モデルを構成する概念に実装を提供するから。Javaや他の多くのツールを使うことで、オブジェクトやそれらの関係性を作成する際に、概念的なオブジェクトモデルと直接的に類似したものになる。
• モデル駆動設計はC言語には限定的にしか適用できない。手続型言語に対応するモデリングパラダイムがないから。

骨格をみなせる: なぜモデルがユーザーにとって重要なのか

実践的モデラ(HANDS ON MODELS)

• 高度なスキルを持つ人が設計し、スキルのない人はそれを組み立てることは多くのプロジェクトを台無しにしてきた。
• どんなチームも、分析・モデリング・設計・プログラミングを分離してしまうことはモデル駆動設計の妨げになる。
• コートを作成する人がモデルに責任を感じていない場合やアプリケーションのためにモデルを機能させる方法を理解していない場合、そのモデルはソフトウェアと無関係になってしまう。コードを変更するとモデルも変わることを、開発者が認識していない場合は、開発者によるリファクタリングによってモデルは力を増すことなく、むしろ力を失うことになる。
• モデラが実装プロセスから切り離されてるる場合、実装に伴う制約に対する感覚をモデラは習得することがないか、できてもすぐに失ってしまう。モデル駆動設計においては、モデルが、効果的な実装を支えながら、ドメインについてのドメインについての主要な知識を抽象化する。