More Related Content
Similar to DDDモデリング勉強会 #6 (20)
Editor's Notes
- ドメインモデルのスコープ
境界付けは難しい
適切な境界がどこか、実際にどうすれば境界を決められるかは、難しい問題
システム全体をみての戦略的な決定。
言語的な境界となる
矛盾無く一貫性を保った概念の集合で表されるもの
- 同じコンテキスト内で話しをしているのに矛盾する
どうも違うコンテキストの言葉が混じっている気がするという違和感
- 現状を書く
問題箇所にはマークをつけたりもする
あまり細かすぎてもわからなくなる
一部抽出して詳細を書いたりも有り
- ドメインモデルを作るにあたって、最初からそのドメインの知識が完璧であり、
モデリングの技術も高く、ばっちりなモデルが作れる・・・なんていうのは、一部の天才か奇跡の産物のようなものである
はじめは、ドメインエキスパートとコミュニケーションを繰り返し
知識を集めつつ、モデル作成⇒精査⇒知識追加⇒モデル改善といったように段々とモデルが深くなっていく
改善はインクリメンタルに行う
現状とかけ離れた理想像を提示する事は、通常は不可能なので、現状見えている問題点を改善する方法のみを決め、実施する。
- アップストリームコンテキストは、ダウンストリームコンテキストに影響を与える
UDがない関係もある
パートナーシップ
- 適当は、ちょっと言いすぎだが、今わかっている現状や知識をもとに、
いったん「えいや!」と書いてみるのも大事。
ウォーターフォールのように厳密に分析・計画された最終状態を表しているものではない
- これが正解だという話ではないが、サブシステムとして分かれているのだから
とっかかりになるだろうということ
- 他にも
コンテキストの過不足
コンテキスト間の関係の集中や複雑さ
似たようなコンテキスト
・・・
実際の業務とのマッピング
- 着目箇所について、詳細なサブドメインやドメインモデル、マッピングを表現して
問題なのかの検討を行う
- 販売管理コンテキスト内にあった発注サブドメインについて、購買管理コンテキストに分離
- 販売管理コンテキストと在庫管理コンテキストの相互依存が解消されたコンテキストマップ。
・コンテキストマップ上だけ書き換えればよいという話ではない。
・実装コードやテストコードなどなどドメインモデルを改善し、改善が達成したら、コンテキストマップに反映をする。