ドメイン駆動設計入門
•
130 likes•45,215 views
関西Javaエンジニアの会'13 7月度 発表資料 http://kanjava.connpass.com/event/2740/
ドメイン駆動設計入門
- 2. エリック・エヴァンスのドメイン駆動設計 エリック・エヴァンス (著), 今関 剛 (監修), 和智 右桂 (翻訳), 牧野 祐子 (翻訳) 出版社： 翔泳社 発売日： 2011/4/9 原書発売日： 2003/8/22 http://www.amazon.co.jp/エリック・エヴァンスのドメイン駆動設計 -IT-Architects’Archive-ソフトウェア開発 の実践-エリック・エヴァンス /dp/4798121967/
- 3. 今日のお話 ● DDD本の概略 ○ ドメイン駆動設計の基本的な考え方 ○ ドメインモデルの構成要素 ○ DDD本に沿って解説 ● DDDの目次 第１部 ドメインモデルを機能させる 第２部 モデル駆動設計の構成要素 第３部 より深い洞察へ向かうリファクタリング 第４部 戦略的設計 今日は ここ！
- 4. ドメインモデルとは？ ● モデル ○ 現実にある”もの”や”こと”を、関心毎に絞ってシンプルに図示したもの ○ 選び抜かれてシンプルにされ、意図的に組み立てられた知識の表現形式 ○ 複数の人間の間で知識を共有するツール ● ドメインモデル ○ システム化の対象となるドメイン（業務）の知識を抽象化して図示したもの ○ ドメイン駆動設計を実践する上で、開発者とドメインエキスパートをつなぐ共通 の知識表現 ● ドメインエキスパート ○ プロジェクトに参加する業務の全体像を詳しく理解している人 ○ DDDにおけるドメインモデルはドメインエキスパートと共同で作り上げるもの
- 6. ユビキタス言語 ● ドメインモデルを用いたチーム内での共通の言語 複雑な開発にはコミュニケーションが重要 ○ ドメインエキスパートと開発者はそれぞれ独自の専門用語で知識を表現し ようとしてしまう ○ ドメインモデルをコミュニケーションにおける共通言語としよう ○ ● ドメインモデルをユビキタスな言語にする ○ ユビキタス言語がプロジェクトの全てのメンバーに行きわたり、設計から開 発、モデルからコードまで全ての成果物に反映されていること ○ ドメインエキスパートはユビキタス言語を通してそのドメインの理解を適切 に伝えられているかを見極める ○ 開発者はユビキタス言語により設計の曖昧さが排除されているかを見極め る
- 7. モデル駆動設計 ● モデルをそのまま実装に落とす手法 ○ ● モデルを基に、コードでそのモデルの概念やモデルそのものを表現する モデルとコードを緊密に関係づける ○ ドメインモデルをユビキタス言語にするためには、その内容をコードにも落と す必要がある ○ ドメインモデルとコードは常に整合性を保っていなければならず、それを実現 する手段としてモデル駆動設計を用いる ● 分析モデルと設計モデルという二分法を捨て去る ○ ビジネスドメインの理解のために分析モデルを作る事があるが、この用途の モデルでは実装の問題が留意されない ○ モデル駆動設計では、分析・設計の両側面から使える単一モデルを探し出す ようモデルを蒸留する
- 8. ドメイン駆動設計とは？ ● ドメインモデルを中心とした設計・開発手法 ● 開発者がドメインエキスパートと共同でドメイン知識を抽象 化したドメインモデルを作り上げる ● ドメインモデルをユビキタス言語としてドメインの知識を共有 化する ● モデル駆動設計によりユビキタス言語化されたドメインモデ ルをそのまま実装に落とし込む ドメイン（業務）の変更につよいアジリティ の高いシステムを作る
- 9. レイヤ化アーキテクチャ ● ドメインを隔離する ○ ○ ドメインオブジェクトをシステムの他の機能から切り離す ドメインオブジェクトが、UIやDBといったソフトウェアの概念から影響を受け にくくする
- 10. モデルの構成要素 ● モデルを表現する要素 ○ ドメインオブジェクトは基本この３つの何れかに分類される Entities Value Objects Services ● モデルのライフサイクル ○ ドメインオブジェクトのライフサイクルを表現・管理するためのパター ン Aggregates Factories Repositories
- 11. Entities ● 抽象的な連続性と同一性 ○ 固有のIDを持ち、実装をまたいだとしても追跡されるような連続性を持つオ ブジェクト ○ 分散環境下でも、永続化前後でも追跡できないといけない ● 属性（状態）に左右されない同一性 ○ ○ 連続性を保証するIDは、オブジェクトの属性値に左右されない ○ 同一性の判断とライフサイクルは、モデル毎に個別に設計する 属性値が全て同じでもIDが異なれば別もの 属性値が異なっていてもIDが同じであれば同じもの ● 具体例 ○ 顧客、口座、注文、在庫、etc...
- 12. Value Objects ● 連続性と同一性が不要なオブジェクト ○ ○ ○ 属性がどんな値であるかに焦点が置かれるもの 一過性のことも多く、操作のために生成されては破棄される 状態を変更できないもの（immutable）として扱う ● 他の何かの状態を記述する属性となる ○ 「何」であるかだけが問題となり、「誰」であるか、あるいは「どれ」であるか は問われないような設計の要素 ○ エンティティの属性としても使用される ● 具体例 ○ 色、量、地域、経路、etc...
- 13. Services ● EntityやValueObjectには不自然な操作 ○ 1つの機能や処理が単体で存在していて、もの（オブジェクト）として扱うの が不自然なものもある ○ 操作であり状態を持たない ● EntityとValueObjectのコントローラ ○ EntityとValueObjectの集合体で構築され、ドメインの能力をまとめ上げる スクリプトとしてふるまうものが多い ○ EntityとValueObjectは、ドメイン層の持つ能力への便利なアクセスを提供 するには、粒度が細かすぎる事が多いための対処 ● サービスはドメイン層だけのものではない ○ アプリケーション層やインフラストラクチャ層にもある ○ ビジネスに関係する処理を持つサービスだけをドメイン層に配置する
- 15. Aggregates（集約） ● オブジェクトのまとまりを作る ○ 関連するオブジェクトの集まりであり、データを変更するための単位 ○ モデル内にある参照をカプセル化するための抽象化 ● 各Aggregateにルートと境界を設ける ○ ルートはAggregateに含まれている特定の１エンティティ ○ 外部オブジェクトから参照できるのはルートのみ ■ 境界内のオブジェクトに対する処理はすべてルートを経由する ■ データベースに問い合わせて直接取得できるのはルートだけ ○ Aggregateに明確な所有権と境界を定義し、関連を最小限に抑える ● 境界内のオブジェクトに対する一貫性を保証する ○ ルートが境界内のオブジェクトの不変条件をチェックする ● 具体例 ○ 「注文」と「注文明細」、「車」と「タイヤ」や「エンジン」などの各種パーツ
- 17. Factories ● オブジェクトやAggregateの生成をカプセル化する ○ ○ ○ 生成されるオブジェクトとクライアントを疎結合に保つ 複雑になりがちな生成処理を隠蔽する 生成するオブジェクトの不変条件を強制する ● オブジェクトを再構築する ○ ○ ライフサイクル中に永続化されたオブジェクトを復元する処理 生成時とは異なる振る舞いになる ■ IDの採番や不変条件のチェック後の振る舞いなど ● ファクトリはドメインモデルではない ○ オブジェクトの生成がドメイン上の重要な意味を持つ事がないため ○ 但し実装には必要なドメインの構成要素
- 21. 京都DDD読書会告知 http://connpass.com/series/246/ ● 京都で行うDDDの読書会 ● 3週間に一度水曜日に開催 ● ○ 次回はモデリングのワークショップ こんな人、大歓迎！ ○ ＤＤＤを読もうと思ってたけど一人で読むの大変だった人 ○ これからＤＤＤをやってみたい人 ○ これを機にＤＤＤを読もうという人
- 22. 参考資料 ● DDD難民に捧げる Domain-Driven Designのエッセンス ○ オブジェクトの広場 ○ http://www.ogis-ri.co. jp/otc/hiroba/technical/DDDEssence/chap1.html ● ドメイン駆動設計・アプリケーション構築編 ○ ストラテジック チョイス ○ http://d.hatena.ne.jp/asakichy/20110509/1304899807