ドメイン駆動設計
https://gyazo.com/55130215011b93397cd223f8c0ffb1de
とは
そもそもドメインとは？
ソフトウェアが対象とする「知識、影響力、または活動の領域」。
ユーザーがプログラムを適用する対象エリアは、ソフトウェアのドメイン。
ドメイン駆動設計（DDD）とは？
ドメイン駆動設計とは、実装を業務の中核をなす概念モデルの発展に深く結びつけることで、複雑なニーズに対応するソフトウェアを開発するためのアプローチ
Eric Evansはなんと言っているのか？
1. ドメインの中核となる複雑さと機会に焦点を当てる
2. ドメイン専門家とソフトウェア専門家のコラボレーションでモデルを探求する
3. 明示的にそれらのモデルを表現するソフトウェアを書く
4. 境界付けられたコンテキスト(＊2)の中のユビキタス言語(＊3)で話す
(＊2)コンテキスト：
特定のモデルが定義され適用される境界（通常、サブシステム、または特定のチームの作業）の説明
(＊3)ユビキタス言語：
ドメインモデルを中心に構造化された言語。
チームのすべてのアクティビティをソフトウェアと結びつけるために、境界付けられたコンテキスト内のすべてのチームメンバーが使用する。
[ドメイン駆動設計の定義についてEric Evansはなんと言っているのかDDD] DDDの全体像
DDDの３つの領域
開発思想：
システムの複雑性に取り組むために、業務の専門家と技術の専門家で言語・モデルの認識を合わせ、継続的に進化させていこう、という考え方
戦略的設計：
ドメインモデリングの前提を揃えるための、モデリング対象を定義する原則と手法(コアドメイン/サブドメイン、境界付けられたコンテキスト、コンテキストマップ等)
戦術的設計
モデルを具体的に表現するためのパターン(エンティティ、レポジトリ、レイヤードアーキテクチャ等)
--.icon
何故ドメイン駆動設計をするのか
以下の問題に対処するため、DDDを用いる
通常、ある業務をシステムに落とし込む時、①現実の業務を適切に抽象化した分析モデルの作成、②分析モデルを基にした設計という2回の射影が行われる
①：ユーザヒアリングによる要件抽出のイメージ
②：要件を基にした仕様書作成/実装のイメージ
起きている問題
分析モデルと設計の乖離
②で、①では存在しない(現実の業務には無い)概念が生まれ、①と②はどんどん乖離されていってしまう
設計と、それにあいまいにしか対応していないモデルとの間の紐づけを維持することは、費用対効果が低いのだ。 (中略) 設計が、あるいは設計の中心となる部分が、ドメインモデルに紐づいていないならば、そのモデルにほとんど価値はなく、ソフトウェアが正確であるかどうかも疑わしい。同じように、モデルと設計された機能との紐づけが複雑だと理解するのが難しく、実際には、設計が変更された時に紐づけを維持できなくなる。分析と設計の間に致命的な亀裂が生じるため、それぞれの作業で得られる洞察は互いに活かされることがないのだ。 --Eric Evans. エリック・エヴァンスのドメイン駆動設計 (Japanese Edition) (Kindle の位置No.1564-1565). Kindle 版. `
DDDの説明
ソフトウェアシステムの一部を設計する際には、紐づけが明らかになるように、ドメインモデルを文字通りの意味で忠実に反映させること。モデルについて再検討し、より自然にソフトウェアに実装されるように修正すること。 (中略) 設計で使用する用語法と責務の基礎的な割り当てをモデルから引き出すこと。コードはモデルの表現となるから、コードに対する変更はモデルに対する変更になるかもしれない。その影響は、プロジェクトの他の活動全体へと適宜伝わっていかなければならない。 -- Eric Evans. エリック・エヴァンスのドメイン駆動設計 (Japanese Edition) (Kindle の位置No.1596-1598). Kindle 版.
--.icon
あとで読む