エリックエバンスのドメイン駆動設計の「第3章 モデルと実装を結びつける」まとめ

エリック・エヴァンスのドメイン駆動設計

エリック・エヴァンスのドメイン駆動設計

今回は、「第3章 モデルと実装を結びつける」のまとめです。

モデル駆動設計

DDDにおけるモデル駆動設計で大事な要素としては以下が挙げられています。

分析モデルと設計の両方の目的に使える単一のモデルを作ること

分析と設計で分離したモデルを扱ってしまうと、それぞれの作業で得られる洞察が互いに活かされない。

これは、以前の記事(エリック・エバンスのドメイン駆動設計の導入まとめ - 「ノクターン(夜想曲)」からの人生復旧)でも記述しましたが、ドメインモデルを中心に、全行程を進めていく際、必要な情報をドメインモデルから取り出し、改善すべき点があれば、ドメインモデルにフィードバックをかけるという話と同じです。

設計で使用する用語と責務の基礎的な割り当てをモデルから引き出すこと

これも、先ほどの話と近い部分になります。

これを実践するためには、以下の点が重要になります。

この辺りの細かい話は、以前のドメイン駆動設計のまとめ記事が役に立つと思います。

モデリングパラダイムを可能とするプログラミング言語を採用

モデルと実装を結びつけることが大事と何度も過去に記述していますが、そもそもモデルにある概念を忠実に表現できるプログラミング言語が必要になります。

なので、ドメイン駆動設計を採用するということは、採用可能なプログラミング言語が絞られるということです。

昔に作られたアプリケーションに対して、ドメイン駆動設計を採用する場合に、この辺りの課題が出てくるかもですね。

僕の現場でも、現場の方針として、独自言語で作られら開発スタイルからオープンな技術に脱出しようと、この1年頑張ってきました。

その際、アプリケーションのリニューアルが必要になってきますが、リニューアルの戦略はものすごく大事だなっと思っています。

ちょっと、脇道にそれましたが、この辺りの話もいつか記事にできたらいいなっと思います。

モデリングとプログラミングでメンバを分離しない

分離したことによるデメリットは以下です。

  • モデルの持つ意図の一部が、引き継ぐ際に失われる

  • モデルが実装によるフィードバックを直接得られない

これも、ドメインモデルを中心とした開発プロセスを回すために必須の要素かと思います。

まとめ

今回の記事は、以下の図に集約されていると思いました。

工程が進むごとに/工程を行ったり来たりするごとに/リリースするごとに、ドメインモデルを蒸留させることが重要ですね。

f:id:mmm-mao:20150416213459j:plain

引用元 【アジャイル開発 X 設計】DDD(ドメイン駆動開発)に入門してみた | For X Developers