DDDモデリング勉強会 #6
- 1.
- 2. DDDモデリング勉強会について 【目的】 • 「エリック・エヴァンスのドメイン駆動設計（DDD本）」を題材と して、DDDの勉強をする • 興味のあるテーマについて、講義+実践（モデリング）を通し て、DDDの手法を理解する •DDD本に完全準拠で進めるわけではなく、自分たちの考えを 含める 1
- 3. DDDモデリング勉強会について 【過去の開催】 #1 DDDの基礎（講義） #2 DDDの基礎（モデリング） #3DDDの基礎（グループモデリング） #4 エンティティ、値オブジェクト（グループモデリング） #5 エンティティ、値オブジェクト（レビュー） 2
- 4. アジェンダ • 境界付けられたコンテキスト • コンテキストマップ •コンテキストマップを作ってみる • コンテキストマップを使ってみる 3
- 5. アジェンダ • 境界付けられたコンテキスト • コンテキストマップ •コンテキストマップを作ってみる • コンテキストマップを使ってみる 4
- 6.
- 7.
- 8. 境界はどうやって決めるのか？ • 初めから完全に線は引けない • ドメインエキスパートとの会話をしつつ必要に応じて 概念を整理していく –会話やモデルの語彙に違和感がある • 同じ「言葉」別の「意味」 • 違う「言葉」同じ「意味」 • 別のコンテキストにも同じような語彙がある – モデルの見た目に違和感がある • 他から参照されないエンティティがある • 多数のエンティティに保持されているエンティティがあ る。 7
- 9. アジェンダ • 境界付けられたコンテキスト • コンテキストマップ •コンテキストマップを作ってみる • コンテキストマップを使ってみる 8
- 10. コンテキストマップって？ • 境界付けられたコンテキストが全体でどのよ うな位置づけにいるのかを把握するツール – 各コンテキスト間の関係 –各コンテキストに含まれるドメイン – 各コンテキストに含まれるドメイン間の関係 (関心 対象の部分を切り出す) – 表現は自由(ホワイトボード等に書いても良い) 9
- 11.
- 12. Cコンテキスト コンテキストマップの例 U D U D U D Bコンテキスト Aコンテキスト ACL OHS/PL U：上流（upstream） D：下流（downstream） OHS：公開ホストサービス（open host service） PL：公表された言語（publiclanguage） ACL：腐敗防止層（anticorruption layer） A1ドメイン A2ドメイン Cドメイン Bドメイン 11
- 13. アジェンダ • 境界付けられたコンテキスト • コンテキストマップ •コンテキストマップを作ってみる • コンテキストマップを使ってみる 12
- 14. コンテキストマップを作ってみる • 随時作る • 作ったものは捨てる •簡単に書けそうなところから手をつける • 適当でもいいから書いてみる 理想形ではなく、あくま で現状を表現する 13
- 15. 次のシナリオで実際に作ってみよう • 自社製品と他社製品の販売をしている会社 の既存の業務システムを段階的にリプレイス する • 販売管理サブシステムと在庫管理サブシステ ムをリプレイスする •人事管理、製造管理、会計管理サブシステム は今回のリプレイス対象外 14
- 16. コンテキストが分かれそうなのは・・ • サブシステム • 外部システム •パッケージ製品 • 業務の組織構造 • ソースのパッケージ • 開発体制 etc. 通常のプロジェクト では、コンテキスト があいまい 15
- 17.
- 18.
- 19. アジェンダ • 境界付けられたコンテキスト • コンテキストマップ •コンテキストマップを作ってみる • コンテキストマップを使ってみる 18
- 20.
- 21.
- 22.
- 23.
- 24.
- 25. DDDモデリング勉強会について 【今後の予定】 #7 コンテキストマップ（モデリング） 5月 (1)お題をもとにコンテキストマップを作ってみる (2) 作ったコンテキストマップから問題を見つける #8 ドメインイベント（講義） 7月 #9 ドメインイベント（モデリング） 9月 24
Editor's Notes
- #7 ドメインモデルのスコープ 境界付けは難しい 適切な境界がどこか、実際にどうすれば境界を決められるかは、難しい問題 システム全体をみての戦略的な決定。 言語的な境界となる 矛盾無く一貫性を保った概念の集合で表されるもの
- #9 同じコンテキスト内で話しをしているのに矛盾する どうも違うコンテキストの言葉が混じっている気がするという違和感
- #11 現状を書く 問題箇所にはマークをつけたりもする あまり細かすぎてもわからなくなる 一部抽出して詳細を書いたりも有り
- #12 ドメインモデルを作るにあたって、最初からそのドメインの知識が完璧であり、 モデリングの技術も高く、ばっちりなモデルが作れる・・・なんていうのは、一部の天才か奇跡の産物のようなものである はじめは、ドメインエキスパートとコミュニケーションを繰り返し 知識を集めつつ、モデル作成⇒精査⇒知識追加⇒モデル改善といったように段々とモデルが深くなっていく 改善はインクリメンタルに行う 現状とかけ離れた理想像を提示する事は、通常は不可能なので、現状見えている問題点を改善する方法のみを決め、実施する。
- #13 アップストリームコンテキストは、ダウンストリームコンテキストに影響を与える UDがない関係もある パートナーシップ
- #15 適当は、ちょっと言いすぎだが、今わかっている現状や知識をもとに、 いったん「えいや！」と書いてみるのも大事。 ウォーターフォールのように厳密に分析・計画された最終状態を表しているものではない
- #18 これが正解だという話ではないが、サブシステムとして分かれているのだから とっかかりになるだろうということ
- #21 他にも コンテキストの過不足 コンテキスト間の関係の集中や複雑さ 似たようなコンテキスト ・・・ 実際の業務とのマッピング
- #22 着目箇所について、詳細なサブドメインやドメインモデル、マッピングを表現して 問題なのかの検討を行う
- #24 販売管理コンテキスト内にあった発注サブドメインについて、購買管理コンテキストに分離
- #25 販売管理コンテキストと在庫管理コンテキストの相互依存が解消されたコンテキストマップ。 ・コンテキストマップ上だけ書き換えればよいという話ではない。 ・実装コードやテストコードなどなどドメインモデルを改善し、改善が達成したら、コンテキストマップに反映をする。