Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

社内 DDD 勉強会 #5

225 views

Published on

社内で行った DDD 勉強会のスライドです

Published in: Software
  • Be the first to comment

  • Be the first to like this

社内 DDD 勉強会 #5

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

×