Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                
SlideShare a Scribd company logo

ドメインロジックの実装方法とドメイン駆動設計

•Download as PPT, PDF•
•
Tadayoshi Sato
Tadayoshi Sato
1 of 48
ドメインロジックの実装方法と ドメイン駆動設計 Ouobpo 佐藤　匡剛 http://ameblo.jp/ouobpo BPStudy 第 7 回 2008 年 3 月 28 日
もくじ 第Ⅰ部　ドメインロジックの実装方法 第Ⅱ部　ドメイン駆動設計の紹介
第Ⅰ部 ドメインロジックの実装方法
3 層アーキテクチャ エンタープライズアプリの典型的アーキテクチャ Web アプリ FW サービスレイヤー DI ／ IoC コンテナ データアクセス FW DAO プレゼンテーション層 ドメイン層 インテグレーション層 POJO アクション アクション アクション POJO POJO POJO DAO インテグレーション ゲートウェイ システム間統合 MW FW ・・・ フレームワーク　　 MW ・・・ ミドルウェア ルールエンジン ワークフローエンジン
ビジネスにとって最も重要な部分 Web アプリ FW サービスレイヤー DI ／ IoC コンテナ データアクセス FW DAO プレゼンテーション層 ドメイン層 インテグレーション層 POJO アクション アクション アクション POJO POJO POJO DAO インテグレーション ゲートウェイ システム間統合 MW ルールエンジン ワークフローエンジン 業務知識を実現している部分＝ドメインロジック
ドメインロジック実装の 3 つのパターン Martin Fowler 『エンタープライズアプリケーションアーキテクチャパターン』より） Transaction Script パターン ドメインロジックをデータと振舞に分け、振舞をスクリプト的に記述する方法。手続き的。 Domain Model パターン ドメインロジックをデータと振舞を合わせたオブジェクトによりモデル化する方法。オブジェクト指向的。 Table Module パターン 上記 2 つの中間的な方法。データと振舞を分けるが、振舞をテーブル毎に構成する。（今回は省略）
Transaction Script パターン （ Martin Fowler 『エンタープライズアプリケーションアーキテクチャパターン』より）
Domain Model パターン （ Martin Fowler 『エンタープライズアプリケーションアーキテクチャパターン』より）
Transaction Script と Domain Model の比較 Transaction Script ○ 構造がシンプル。 OO に慣れてないプログラマにも分かりやすい × ロジックが複雑になると重複がひどくなる Domain Model ○ 複雑なロジックも重複なくきれいにモデル化できる × 非常にハードルが高い。データベースとのマッピングも大変
日本では・・・ Transaction Script が主流 Domain Model を採用したプロジェクトは見たことがない ⇒ 　なぜ？ ちまたに Domain Model のサンプルコードがほとんどないからでは？ PofEAA もちょっとしかサンプルコードを載せていない 雑誌でも Domain Model のサンプルコードはほとんどない フレームワーク、 DI コンテナに付いてくるサンプルコードはだいたい Transaction Script 寄り ⇒ 　それではサンプルコードを見てみよう！
給与計算システムの例 ユースケース図
給与システムのドメインモデル
給与システムのデータモデル
給与システムのサンプルコード Google Code プロジェクトの SVN リポジトリ上に公開されています。 http:// ouobpo.googlecode.com/svn/trunk/ 　 bpstudy-200803/
Transaction Script 版の設計クラス図
Domain Model 版の設計クラス図
Domain Model パターンの真のメリット① 複雑なロジックを可視化できる 【 Transaction Script 】 【 Domain Model 】 文章で書かれた仕様がそのままソースコードに 設計クラス図 ？ ソースコードの構造が分かる .xls ユースケース記述 ビジネスルール定義書 ソースコード .xls ユースケース記述 ビジネスルール定義書 ソースコード
Domain Model パターンの真のメリット② ソースコードそのものはシンプルになる クラス／インタフェースの数が減る Logic + Entity ⇒ DomainObject メソッドの引数が減る pay(employee, year, month) ⇒ pay(year, month) メソッド内の Getter メソッド呼び出しが減る entity.getXxx() ⇒ this.xxx Getter ／ Setter メソッドが減る
Domain Model を採用する際の障壁 3 つの障壁 Domain Model は修得が難しく、開発者の確保が難しい OO 的な考え方の普及、技術者の底上げが必要 そもそも高度な専門分野なのに、ソフトウェア工学の学位をもった技術者がほとんどいないという、日本の IT 業界の構造的な問題？ DI との親和性が低い 確かに Seasar の SMART デプロイ、 S2Dao とは相性が悪い DI コンテナ、フレームワーク側が頑張ればなんとかなるのでは？ 日本のビジネスはデータと振舞を分けた方が自然にモデル化できる、という意見 たまたまそういう仕事が今 SI 業界で多いだけはないか？ プロセス重視のドメイン（財務シミュレーション、生産ライン管理、給与計算など）でデータと振舞を分けるメリットはあるのか？
Domain Model の作り方 （作り方が分からないという方のために） GRASP パターン（ Craig Larman 『実践 UML 』） 情報エキスパート（ Information Expert ） 生成者（ Creator ） コントローラ（ Controller ） 低結合性（ Low Coupling ） 高凝集性（ High Cohesion ） 多相性（ Polymorphism ） でっち上げ（ Pure Fabrication ） 間接化（ Indirection ） バリエーション防護（ Protected Variations ） この辺がとくに重要！
とはいえ、そんなに複雑なビジネスロジックってあるの？ 最近の Web アプリケーションは、ほとんどが CRUD 処理のみ 「ドメインロジック層なんていらないじゃん」 画面や DB から直接作ってしまった方がいいのでは？ すべてをリッチにドメインモデリングする必要はない 私の経験だと、ロジックが複雑な部分はアプリ全体の 10% くらい ビジネス的に重要な部分（＝ロジックが複雑な部分）だけ、優秀なリソースを投入してきちんとモデリングすればいい ロジックの薄い部分は手間を掛けず、ローコストに瞬殺する Transaction Script なり Active Record なりを使う 外注する パッケージ製品を買ってきて作らずに済ます
とはいえ、そんなに複雑なビジネスロジックってあるの？　（つづき） そもそもシステムが頭を使っていないからではないか？ Web CRUD なアプリは、結局オペレータが頭を使っている 戦略的なシステムは、もっと頭を使うはず ドメインリッチなシステムは省人化を進める 今まで人間がやっていた業務をシステムが肩代わりする 会社の最適化に貢献するが、従業員削減にもつながってしまう 従業員からすると好ましくないシステム 強い権限をもつ CIO がトップダウンにやらないと難しい リストラが当たり前の欧米（？）でドメインモデルが流行って、日本でなかなか流行らない理由の 1 つ？
余談
DAO と O/R マッパの違い DAO ロジックに対して DB ゲートウェイの役割をするもの ロジックが DAO を呼び出す O/R マッパ ドメインオブジェクトと DB とをマッピングするもの ドメインオブジェクトは O/R マッパと DB の存在を知らなくていい
Hibernate ／ JPA の間違った使い方 Hibernate ／ JPA は、本来 O/R マッパ なのに、 DAO の実装に使ってしまうことがよくある
第Ⅱ部 ドメイン駆動設計の紹介
『 Domain-Driven Design 』（ Eric Evans 著） 一冊まるまる「ドメインモデリング」について扱った書籍 「ソフトウェアの真の複雑さに挑戦する」 パターン本の 1 つ 40 パターン＋ 1 アンチパターン 海外では大ブームに Ralph Johnson （ GoF の 1 人）： 「 4 、 5 回は読み直した」 Rod Johnson （ Spring 創始者）： 「 Java 開発のこれからはリッチドメインモデルだ」
ドメイン駆動設計とはなにか ドメインモデルを中心にすえた設計思想 ドメインモデルはドメイン知識を深めながら反復的（ iterative ）に設計していく ドメインモデルを開発者とユーザ・専門家の間の共通言語に ドメインモデル⇔実装コード（や他の成果物）の対応関係を最後まで維持する
DDD 本の構成 DDD の基本思想 DDD の基本的な考え方や前提 モデル駆動設計（ MDD ）の構成要素 MDD を実現する OO ベストプラクティス。既にあるドメインモデルをいかにソフトウェア設計に落とし込むか ドメインリファクタリング ドメインモデルにドメイン知識を反映させ、より深いモデルにしていくためのノウハウ 戦略的デザイン 1 アプリの範囲を超えて、大規模開発／ SOA に DDD を適用していく方法
MDD 実践的 モデラー ユビキタス 言語 DDD の基本思想 基本要素 ライフサイクル 深いモデル + しなやかな設計 制約 プロセス 仕様 抽象化 分割 コンテキスト マッピング ドメインの 優先付け 「大きな絵」 の共有 MDD の構成要素 ドメインリファクタリング 戦略的デザイン 単一アプリケーションの開発 大規模開発／ SOA エンティティ 値 サービス モジュール 集約 ファクトリ リポジトリ 中核ドメイン 汎用サブ ドメイン コンテキスト マップ 継続的 統合 メタファ 責務の 階層
Ⅰ . DDD の基本思想 ドメインモデルを、プロジェクトを駆動する 「共通言語」 にすること DDD の基本三原則 Ubiquitous Language （ユビキタス言語）パターン Model-Driven Design （モデル駆動設計）パターン Hands-On Modeler （実践的モデラー）パターン
Ⅱ . MDD の構成要素 これまでの OO 方法論の集大成 責務駆動設計（ Responsibility-Driven Design ） 契約による設計（ Design by Contract ） GRASP パターン エンタープライズアプリケーションアーキテクチャパターン
MDD を構成するパターン まずドメイン層を分離する Layered Architecture （層状アーキテクチャ）パターン Smart UI （利口な UI ）アンチパターン ソフトウェアによってモデルを表現する Entities （エンティティ）パターン Value Objects （値オブジェクト）パターン Services （サービス）パターン Modules （モジュール）パターン
MDD を構成するパターン（つづき） ドメインオブジェクトのライフサイクルを設計する Aggregates （集約）パターン Factories （ファクトリ）パターン Repositories （リポジトリ）パターン
Ⅲ . ドメインリファクタリング 現実のドメインモデリングは古典的 OO 方法論が教えるほど単純ではない （ × ）「名詞をクラスにして、動詞をメソッドにする」 反復的にモデルを深めていく必要がある リファクタリングの 3 つのレベル マイクロリファクタリング パターン指向リファクタリング ドメインリファクタリング ドメインリファクタリングの 2 つの柱 深いモデル（ deep model ） しなやかな設計（ supple design ）
深いモデル 隠れた概念を発掘する 見つけづらい概念には、以下がある 制約 プロセス 仕様 Specifications （仕様）パターン
しなやかな設計 理解を容易にする抽象化 Intention-Revealing Interfaces （意図の明白なインタフェース）パターン Side-Effect-Free Functions （副作用のない関数）パターン Assertions （表明）パターン 変更しやすい適切な分割 Conceptual Contours （概念の輪郭）パターン Standalone Classes （独立したクラス群）パターン Closures of Operations （閉じた操作）パターン
Ⅳ . 戦略的デザイン 単一アプリの枠組みを超えたシステム構築 大規模開発や EAI 、 SOA の世界 企業情報システムの全体構造（ EA ）に深く関係する 経営戦略的（ strategic ）な視点が求められる 全企業的な視野においても、ドメインを深く反映したシステムこそが大きなビジネス価値につながる 「戦略的デザイン」の構成 コンテキスト（ context ） 蒸留（ distillation ） 大規模な構造（ large-scale structure ）
コンテキスト－他システムとの統合 システム統合における課題 異なるドメインモデル間の不整合をいかに解決するか コンテキストの境界を定める Bounded Context （コンテキスト境界）パターン Continuous Integration （継続的な統合）パターン Context Map （コンテキストマップ）パターン
コンテキスト－他システムとの統合 （つづき） コンテキスト間の 6 つの関係 Shared Kernel （共有カーネル）パターン Customer/Supplier Development Teams （顧客／供給者の開発チーム）パターン Conformist （順応者）パターン Anticorruption Layer （腐敗防止層）パターン Separate Ways （別々の道）パターン Open Host Service （公開ホストサービス）パターン
コンテキスト－他システムとの統合 （つづき） 補足的なパターン Published Language （公表された言語）パターン
蒸留－戦略的な優先付け 企業のコアコンピタンス（競争力）をいかに向上させるか 限りあるリソースをどこに投入するかが大きな課題 ドメインの優先順位付け Core Domain （中核ドメイン）パターン Generic Subdomains （汎用サブドメイン）パターン
蒸留－戦略的な優先付け（つづき） 中核ドメインの文書化方法 Domain Vision Statement （ドメインビジョン説明書）パターン Highlighted Core （中核のハイライト）パターン 中核をさらに中核らしく磨き上げる Cohesive Mechanisms （凝集されたメカニズム）パターン Segregated Core （中核の隔離）パターン Abstract Core （中核の抽象化）パターン
大規模な構造－「大きな絵」の共有 大規模システムの開発をいかに成功させるか チームがアーキテクチャレベルの「大きな絵」を共有し、同じ目標意識をもって協調することが肝心 大規模な構造を扱う際の基本姿勢 Evolving Order （進化則）パターン
大規模な構造－「大きな絵」の共有 （つづき） 大規模な構造の 3 つのパターン System Metaphor （システムのメタファ）パターン Responsibility Layers （責務の階層構造）パターン Knowledge Level （知識レベル）パターン 幸福な DDD の最終形態 Pluggable Component Framework （可換コンポーネントフレームワーク）パターン
最後に
なぜドメインモデルなのか？ それはドメインモデルが楽しいから！ （がんばれば）複雑なシステムでもきれいに構築可能 オブジェクトという部品を使ってモノづくりする楽しさ 自分が作ったシステムの形を視覚的に実感できる トランザクションスクリプトより、なんか作ってて楽しい 結局、 Ruby でプログラミングするのがなぜか楽しいのと同じことでは？
ドメインモデル作りを 楽しみましょう！

More Related Content

ドメインロジックの実装方法とドメイン駆動設計

  • 1. ドメインロジックの実装方法と ドメイン駆動設計 Ouobpo 佐藤　匡剛 http://ameblo.jp/ouobpo BPStudy 第 7 回 2008 年 3 月 28 日
  • 4. 3 層アーキテクチャ エンタープライズアプリの典型的アーキテクチャ Web アプリ FW サービスレイヤー DI ／ IoC コンテナ データアクセス FW DAO プレゼンテーション層 ドメイン層 インテグレーション層 POJO アクション アクション アクション POJO POJO POJO DAO インテグレーション ゲートウェイ システム間統合 MW FW ・・・ フレームワーク　　 MW ・・・ ミドルウェア ルールエンジン ワークフローエンジン
  • 5. ビジネスにとって最も重要な部分 Web アプリ FW サービスレイヤー DI ／ IoC コンテナ データアクセス FW DAO プレゼンテーション層 ドメイン層 インテグレーション層 POJO アクション アクション アクション POJO POJO POJO DAO インテグレーション ゲートウェイ システム間統合 MW ルールエンジン ワークフローエンジン 業務知識を実現している部分＝ドメインロジック
  • 6. ドメインロジック実装の 3 つのパターン Martin Fowler 『エンタープライズアプリケーションアーキテクチャパターン』より） Transaction Script パターン ドメインロジックをデータと振舞に分け、振舞をスクリプト的に記述する方法。手続き的。 Domain Model パターン ドメインロジックをデータと振舞を合わせたオブジェクトによりモデル化する方法。オブジェクト指向的。 Table Module パターン 上記 2 つの中間的な方法。データと振舞を分けるが、振舞をテーブル毎に構成する。（今回は省略）
  • 7. Transaction Script パターン （ Martin Fowler 『エンタープライズアプリケーションアーキテクチャパターン』より）
  • 8. Domain Model パターン （ Martin Fowler 『エンタープライズアプリケーションアーキテクチャパターン』より）
  • 9. Transaction Script と Domain Model の比較 Transaction Script ○ 構造がシンプル。 OO に慣れてないプログラマにも分かりやすい × ロジックが複雑になると重複がひどくなる Domain Model ○ 複雑なロジックも重複なくきれいにモデル化できる × 非常にハードルが高い。データベースとのマッピングも大変
  • 10. 日本では・・・ Transaction Script が主流 Domain Model を採用したプロジェクトは見たことがない ⇒ 　なぜ？ ちまたに Domain Model のサンプルコードがほとんどないからでは？ PofEAA もちょっとしかサンプルコードを載せていない 雑誌でも Domain Model のサンプルコードはほとんどない フレームワーク、 DI コンテナに付いてくるサンプルコードはだいたい Transaction Script 寄り ⇒ 　それではサンプルコードを見てみよう！
  • 14. 給与システムのサンプルコード Google Code プロジェクトの SVN リポジトリ上に公開されています。 http:// ouobpo.googlecode.com/svn/trunk/ 　 bpstudy-200803/
  • 17. Domain Model パターンの真のメリット① 複雑なロジックを可視化できる 【 Transaction Script 】 【 Domain Model 】 文章で書かれた仕様がそのままソースコードに 設計クラス図 ？ ソースコードの構造が分かる .xls ユースケース記述 ビジネスルール定義書 ソースコード .xls ユースケース記述 ビジネスルール定義書 ソースコード
  • 18. Domain Model パターンの真のメリット② ソースコードそのものはシンプルになる クラス／インタフェースの数が減る Logic + Entity ⇒ DomainObject メソッドの引数が減る pay(employee, year, month) ⇒ pay(year, month) メソッド内の Getter メソッド呼び出しが減る entity.getXxx() ⇒ this.xxx Getter ／ Setter メソッドが減る
  • 19. Domain Model を採用する際の障壁 3 つの障壁 Domain Model は修得が難しく、開発者の確保が難しい OO 的な考え方の普及、技術者の底上げが必要 そもそも高度な専門分野なのに、ソフトウェア工学の学位をもった技術者がほとんどいないという、日本の IT 業界の構造的な問題？ DI との親和性が低い 確かに Seasar の SMART デプロイ、 S2Dao とは相性が悪い DI コンテナ、フレームワーク側が頑張ればなんとかなるのでは？ 日本のビジネスはデータと振舞を分けた方が自然にモデル化できる、という意見 たまたまそういう仕事が今 SI 業界で多いだけはないか？ プロセス重視のドメイン（財務シミュレーション、生産ライン管理、給与計算など）でデータと振舞を分けるメリットはあるのか？
  • 20. Domain Model の作り方 （作り方が分からないという方のために） GRASP パターン（ Craig Larman 『実践 UML 』） 情報エキスパート（ Information Expert ） 生成者（ Creator ） コントローラ（ Controller ） 低結合性（ Low Coupling ） 高凝集性（ High Cohesion ） 多相性（ Polymorphism ） でっち上げ（ Pure Fabrication ） 間接化（ Indirection ） バリエーション防護（ Protected Variations ） この辺がとくに重要！
  • 21. とはいえ、そんなに複雑なビジネスロジックってあるの？ 最近の Web アプリケーションは、ほとんどが CRUD 処理のみ 「ドメインロジック層なんていらないじゃん」 画面や DB から直接作ってしまった方がいいのでは？ すべてをリッチにドメインモデリングする必要はない 私の経験だと、ロジックが複雑な部分はアプリ全体の 10% くらい ビジネス的に重要な部分（＝ロジックが複雑な部分）だけ、優秀なリソースを投入してきちんとモデリングすればいい ロジックの薄い部分は手間を掛けず、ローコストに瞬殺する Transaction Script なり Active Record なりを使う 外注する パッケージ製品を買ってきて作らずに済ます
  • 22. とはいえ、そんなに複雑なビジネスロジックってあるの？　（つづき） そもそもシステムが頭を使っていないからではないか？ Web CRUD なアプリは、結局オペレータが頭を使っている 戦略的なシステムは、もっと頭を使うはず ドメインリッチなシステムは省人化を進める 今まで人間がやっていた業務をシステムが肩代わりする 会社の最適化に貢献するが、従業員削減にもつながってしまう 従業員からすると好ましくないシステム 強い権限をもつ CIO がトップダウンにやらないと難しい リストラが当たり前の欧米（？）でドメインモデルが流行って、日本でなかなか流行らない理由の 1 つ？
  • 24. DAO と O/R マッパの違い DAO ロジックに対して DB ゲートウェイの役割をするもの ロジックが DAO を呼び出す O/R マッパ ドメインオブジェクトと DB とをマッピングするもの ドメインオブジェクトは O/R マッパと DB の存在を知らなくていい
  • 25. Hibernate ／ JPA の間違った使い方 Hibernate ／ JPA は、本来 O/R マッパ なのに、 DAO の実装に使ってしまうことがよくある
  • 27. 『 Domain-Driven Design 』（ Eric Evans 著） 一冊まるまる「ドメインモデリング」について扱った書籍 「ソフトウェアの真の複雑さに挑戦する」 パターン本の 1 つ 40 パターン＋ 1 アンチパターン 海外では大ブームに Ralph Johnson （ GoF の 1 人）： 「 4 、 5 回は読み直した」 Rod Johnson （ Spring 創始者）： 「 Java 開発のこれからはリッチドメインモデルだ」
  • 28. ドメイン駆動設計とはなにか ドメインモデルを中心にすえた設計思想 ドメインモデルはドメイン知識を深めながら反復的（ iterative ）に設計していく ドメインモデルを開発者とユーザ・専門家の間の共通言語に ドメインモデル⇔実装コード（や他の成果物）の対応関係を最後まで維持する
  • 29. DDD 本の構成 DDD の基本思想 DDD の基本的な考え方や前提 モデル駆動設計（ MDD ）の構成要素 MDD を実現する OO ベストプラクティス。既にあるドメインモデルをいかにソフトウェア設計に落とし込むか ドメインリファクタリング ドメインモデルにドメイン知識を反映させ、より深いモデルにしていくためのノウハウ 戦略的デザイン 1 アプリの範囲を超えて、大規模開発／ SOA に DDD を適用していく方法
  • 30. MDD 実践的 モデラー ユビキタス 言語 DDD の基本思想 基本要素 ライフサイクル 深いモデル + しなやかな設計 制約 プロセス 仕様 抽象化 分割 コンテキスト マッピング ドメインの 優先付け 「大きな絵」 の共有 MDD の構成要素 ドメインリファクタリング 戦略的デザイン 単一アプリケーションの開発 大規模開発／ SOA エンティティ 値 サービス モジュール 集約 ファクトリ リポジトリ 中核ドメイン 汎用サブ ドメイン コンテキスト マップ 継続的 統合 メタファ 責務の 階層
  • 31. Ⅰ . DDD の基本思想 ドメインモデルを、プロジェクトを駆動する 「共通言語」 にすること DDD の基本三原則 Ubiquitous Language （ユビキタス言語）パターン Model-Driven Design （モデル駆動設計）パターン Hands-On Modeler （実践的モデラー）パターン
  • 32. Ⅱ . MDD の構成要素 これまでの OO 方法論の集大成 責務駆動設計（ Responsibility-Driven Design ） 契約による設計（ Design by Contract ） GRASP パターン エンタープライズアプリケーションアーキテクチャパターン
  • 33. MDD を構成するパターン まずドメイン層を分離する Layered Architecture （層状アーキテクチャ）パターン Smart UI （利口な UI ）アンチパターン ソフトウェアによってモデルを表現する Entities （エンティティ）パターン Value Objects （値オブジェクト）パターン Services （サービス）パターン Modules （モジュール）パターン
  • 34. MDD を構成するパターン（つづき） ドメインオブジェクトのライフサイクルを設計する Aggregates （集約）パターン Factories （ファクトリ）パターン Repositories （リポジトリ）パターン
  • 35. Ⅲ . ドメインリファクタリング 現実のドメインモデリングは古典的 OO 方法論が教えるほど単純ではない （ × ）「名詞をクラスにして、動詞をメソッドにする」 反復的にモデルを深めていく必要がある リファクタリングの 3 つのレベル マイクロリファクタリング パターン指向リファクタリング ドメインリファクタリング ドメインリファクタリングの 2 つの柱 深いモデル（ deep model ） しなやかな設計（ supple design ）
  • 36. 深いモデル 隠れた概念を発掘する 見つけづらい概念には、以下がある 制約 プロセス 仕様 Specifications （仕様）パターン
  • 37. しなやかな設計 理解を容易にする抽象化 Intention-Revealing Interfaces （意図の明白なインタフェース）パターン Side-Effect-Free Functions （副作用のない関数）パターン Assertions （表明）パターン 変更しやすい適切な分割 Conceptual Contours （概念の輪郭）パターン Standalone Classes （独立したクラス群）パターン Closures of Operations （閉じた操作）パターン
  • 38. Ⅳ . 戦略的デザイン 単一アプリの枠組みを超えたシステム構築 大規模開発や EAI 、 SOA の世界 企業情報システムの全体構造（ EA ）に深く関係する 経営戦略的（ strategic ）な視点が求められる 全企業的な視野においても、ドメインを深く反映したシステムこそが大きなビジネス価値につながる 「戦略的デザイン」の構成 コンテキスト（ context ） 蒸留（ distillation ） 大規模な構造（ large-scale structure ）
  • 39. コンテキスト－他システムとの統合 システム統合における課題 異なるドメインモデル間の不整合をいかに解決するか コンテキストの境界を定める Bounded Context （コンテキスト境界）パターン Continuous Integration （継続的な統合）パターン Context Map （コンテキストマップ）パターン
  • 40. コンテキスト－他システムとの統合 （つづき） コンテキスト間の 6 つの関係 Shared Kernel （共有カーネル）パターン Customer/Supplier Development Teams （顧客／供給者の開発チーム）パターン Conformist （順応者）パターン Anticorruption Layer （腐敗防止層）パターン Separate Ways （別々の道）パターン Open Host Service （公開ホストサービス）パターン
  • 41. コンテキスト－他システムとの統合 （つづき） 補足的なパターン Published Language （公表された言語）パターン
  • 42. 蒸留－戦略的な優先付け 企業のコアコンピタンス（競争力）をいかに向上させるか 限りあるリソースをどこに投入するかが大きな課題 ドメインの優先順位付け Core Domain （中核ドメイン）パターン Generic Subdomains （汎用サブドメイン）パターン
  • 43. 蒸留－戦略的な優先付け（つづき） 中核ドメインの文書化方法 Domain Vision Statement （ドメインビジョン説明書）パターン Highlighted Core （中核のハイライト）パターン 中核をさらに中核らしく磨き上げる Cohesive Mechanisms （凝集されたメカニズム）パターン Segregated Core （中核の隔離）パターン Abstract Core （中核の抽象化）パターン
  • 45. 大規模な構造－「大きな絵」の共有 （つづき） 大規模な構造の 3 つのパターン System Metaphor （システムのメタファ）パターン Responsibility Layers （責務の階層構造）パターン Knowledge Level （知識レベル）パターン 幸福な DDD の最終形態 Pluggable Component Framework （可換コンポーネントフレームワーク）パターン
  • 47. なぜドメインモデルなのか？ それはドメインモデルが楽しいから！ （がんばれば）複雑なシステムでもきれいに構築可能 オブジェクトという部品を使ってモノづくりする楽しさ 自分が作ったシステムの形を視覚的に実感できる トランザクションスクリプトより、なんか作ってて楽しい 結局、 Ruby でプログラミングするのがなぜか楽しいのと同じことでは？