社内 DDD 勉強会 #5
•Descargar como PPTX, PDF•
0 recomendaciones•810 vistas
社内で行った DDD 勉強会のスライドです
Recomendados
Más contenido relacionado
Similar a 社内 DDD 勉強会 #5
Similar a 社内 DDD 勉強会 #5 (20)
Más de shingo suzuki
社内 DDD 勉強会 #5
- 2. 注意事項 • 発表資料は後で SlideShare にあげます
- 3. 今回の範囲 • 第1部 ドメインモデルを機能させる • 第2部 モデル駆動設計の構成要素 • 第3部 より深い洞察へ向かうリファクタリング • 第4部 戦略的設計 • 蒸留 • コンテキスト • 大規模な構造
- 4. 今回の内容 • 戦略的な設計 • 複雑なプロジェクトにどう対処するか？ • 巨大なモデル • 巨大なチーム • テクニック • ドメインを蒸留する • 境界づけられたコンテキストでモデルを分割する • 大規模な構造を設計する
- 5. ドメインの「蒸留」 ドメインから「コア」となる部分を見つける • コアドメイン • アプリケーションの目的を最もよく表現しているサブドメイン • 優先順位高、このドメインに一番注力するべき • 支援サブドメイン • アプリケーション固有であるが、補助的なもの • 優先順位中、必要であるがコアドメインより優先度は低くする • 汎用サブドメイン • アプリケーション固有でないドメイン • 優先順位低、既製品や外部への委託も検討
- 7. コアとなるドメインを切り出す • コアドメインであること強調する • コアドメインの説明と責務を記述したドキュメントを置いておく • コアであることを示すフラグを立てておく • 本質的でないものを分離する • アルゴリズムなどは別個の軽量なフレームワークに分離する • ドメイン内でも補助的なモデルがあれ隔離する • 抽象化して関係を減らす • コアドメインでは重要な関係・相互作用だけのこす • 詳細な実装はサブドメイン側のモジュールに移動する
- 8. 境界づけられたコンテキスト • 巨大な単一のモデルは扱いづらい • 調整にかかるオーバーヘッドが大きくなりすぎる • ある機能についてはモデルが要求を満たしていないかもしれない • モデルが複数あるとどのコンテキストで適用するべきか不明瞭 そこで • 明確に境界を設けたコンテキストをつくる • ドメインモデルはある一つのコンテキストに属するようにする
- 9. もしモデルを分割しないとしたら • 戦略として、こまめにマージを行いモデルの分離を防ぐ必要が ある • 大きく乖離した後のマージは難しくなる • プロジェクトでは以下の活動が必要になる • マージテクニック • 自動化されたビルド・デプロイ • 自動化されたテストスイート • 変更が統合されない期間に対して妥当な短さの上限を設定するルール • 決まってないプロジェクトは多い気がする
- 10. コンテキストでモデルを分割する • コンテキスト境界は次の視点で決める • チーム編成 • アプリケーション特有の機能 • コードベースetcの物理的な観点 • サブドメインに一致しているとよい • コンテキスト境界を定めたら、コンテ キストマップを作成する • コンテキスト同士の関係を記述するもの • 簡単な図で十分 変換処理、API呼 び出しなど
- 13. コンテキスト間の関係パターン ベストプラクティスではない。 プロジェクトがどのような状況にあるか、のパターン集 • 大きな泥だんご • 共有カーネル • 顧客/供給者 • 順応者 • 腐敗防止層 • 別々の道 • 公開ホストサービス • 公表された言語
- 14. 大きな泥だんご • “大きな泥だんご”システムは、通常、長期間開発されたもので あり、多様な部品からなる異なる個々人が開発して構成された ものである。体系立てられたアーキテクチャやプログラミング 研修を学んでいない人々によって構築されたシステムは、しば しばこのようなシステムになる。(wikipediaから引用) • もっとも普及しているパターン • たいていの場合、巨大なひとつのコンテキストしか存在しない • レガシーなシステムなど • こういうパターンに出会ってしまったら、ドメインモデリング は諦めて隔離する
- 15. 共有カーネル • 一部のモデルを複数のコンテ キスト共有するパターン • このパターンでは • ２つのチームで共有するドメイ ンモデルのサブセットを合意す る • 頻繁に統合する
- 16. 顧客/供給者 • 上流・下流に分かれている場合 • 下流は上流に依存する • 上流は下流に依存されない • このパターンでは： • ２つのチーム間に明確な顧客/供給 者の関係を確立する • 計画には下流のチームが上流の チームに対して顧客としての役割 を果たすようにすること • 下流の要件に必要となる作業につ いて顧客・供給者で交渉する 供給者 顧客
- 17. 順応者 • 顧客/供給者の関係に近いが、上流側に 下流チームの要求にこたえる動機がな い • この場合 • 上流チームのモデルに隷従する。下 流側でモデルを作らない • 上流のモデルを使用し、下流側では モデルを立てない 上流 下流
- 18. 腐敗防止層 • 他の巨大なシステムと接続する必要があ る場合 • レガシーなシステム • 大きな泥だんご • この場合： • 隔離するレイヤを作成する 素晴らしい設計 ひどいシステム 腐敗防止層 アダプター ファサードなど
- 19. 公開ホストサービス • あるコンテキストが多くの外部から共有される • ひとつひとつの関係ごとに変換処理を用意するのはコストが高い • この場合 • プロトコルを公開して共有して利用できるようにする • プロトコルを公開し、サブシステムと統合する必要がある人が使用で きるようにする
- 20. 公表された言語 • 公開ホストサービスに近いが、既存のドメインモデル間の直接 的な変換では適切でない • 既存のモデルが複雑すぎたり、逆に過度に分割されている • この場合 • 必要なドメインの情報をコミュニケーションにおける共通の媒体とし て表現できる、明確にドキュメント化された共有言語を使用する • XML や JSON、ある特定の DSL なども
- 21. 大規模な構造を設計する • 大規模な構造を設計する原則 • 反復的な開発 • システムのメタファを共有する • 責務を持ったレイヤに分割する • 知識レベルと業務レベルを分離する
- 22. 反復的な開発 • ウォーターフォールモデルは避けた方がよい • 反復的に開発して、設計と実装をともに進化させる • 場合によっては途中で全く別の種類の構造に変更する • 設計とモデルに関する意思決定を制約しすぎない
- 23. システムのメタファを共有する • システムを説明するのに役に立つメタファがあれば設計に採用 する • メタファを中心に設計し、ユビキタス言語に取り入れる • ただし • メタファは不正確なものなので、常に障害にそなえる • 素朴な＝ドメインモデルそのものをメタファにしない
- 24. 責務を持ったレイヤに分割する • 概念上の依存関係を調べること • ドメインに自然なレイヤが設定出来たらそれに責務を割り当て る • ドメインオブジェクト・集約・モジュールの責務がレイヤに与 えられた責務の範囲に収まるようにする
- 25. 責務を持ったレイヤの例 経路偏向ポリシー経路選択サービス 顧客 経路仕様 輸送日程 貨物 運送工程 意思決定支援 業務 能力 • 意思決定支援レイヤ • 計画作成と意思 決定 • 業務レイヤ • 企業の活動 • 能力レイヤ • 業務を行うため のリソース
- 26. 知識レベルと業務レベルの分離 • 業務レベルオブジェクトに対して、知識レ ベルのオブジェクトを作成する • 知識レベルのオブジェクトは、業務レ ベルのオブジェクトがどう振る舞うべ きかを記述する • 例） • 「従業員」の「給与」は従業員自体で なく、「従業員のタイプ」で決定され る • 「従業員」とは別に「従業員のタイ プ」クラスを作る 物事 何らかの知識 物事のタイプ 知識レベル 業務レベル 振る舞いの ストラテジ
- 27. まとめ • ドメインをリファクタリングしてコアとなるドメインを探す • コンテキストを作り、巨大なモデルを分割する • 大規模なプロジェクトでもよく分割されたモデルを目指す