前回の記事
【ミライトデザイン社内勉強会#10】「IDDD本から理解するドメイン駆動設計」輪読会~1章「DDDへの誘い」~
実践DDD本 第2章「ドメイン」「サブドメイン」「境界づけられたコンテキスト」を読み解く (1/4)：CodeZine（コードジン）
コアドメインが分割されることとかあるの？１アプリケーション１コアドメインではないの？
- 1システム1コアドメインが理想。マストではないけど。
「コアドメイン」とは事業的に最も重要で戦略的に不可欠な部分です。
IDDDでは、1つの「コアドメイン（もしくはサブドメイン）」に、1つの「境界づけられたコンテキスト」が対応している状態が最適だとされています。
「商品」という言語が、2つ以上の意味を持たないように「境界づけられたコンテキスト」を適切に分割する、とあるが、入荷待ち、着荷品ごとにコアドメインを分けるの？商品に入荷待ちや着荷品という状態を持たすのではダメなの？
-
状態が違えばモデルをわけろっていう話ではない。
- 例えば、有料会員、無料会員で対して違いがないのであれば、1つの会員モデルで状態が違うだけでも構わない。
- 有料会員と無料会員で全く意味が変わって来るのであれば、それはモデルを分けるべき
- 別の例いうと、管理画面で権限によって振る舞いが変わる場合、ユーザーがもってる権限オブジェクトが違うだけの場合もある。
- この場合は、権限はただのユーザーの一属性。
- 同じモデルなのか、別のモデルにした方がいいのかは考えないといけない。
-
Amazonとかの規模がおおきいシステムでは予約管理システム、在庫管理システムのようにコンテキストを分けた方がいい場合がある。
- この場合、在庫管理は在庫管理システムで管理して「商品」は在庫品としての意味しか持たない。
-
小さいシステムでは予約中の商品は、予約中商品モデルを作ればいい（もしくは、商品に状態をもたせるだけですむなら、予約中という状態で考えるか）
-
言葉が大きくなりすぎないようにしないといけない
-
端的にいうと同じ言葉なのに別の物を指してる状態にならないようにしようって話。
-
1つのモデルが複数の意味を持たないようにする
-
1つの呼び名が複数の意味を持たないようにする
-
例えば、チーム内で「商品」という単語が出た時に、それが「在庫品」なのか「不良品」のことを指しているのかわからず、認識に齟齬が生じる状態にあってはいけない。
境界づけられたコンテキストで１アプリケーションとして成り立つ？
- 成り立つ。
- 必ずしも１アプリケーションという訳ではないけど。
- パッケージを分けているだけの場合もある。
- 境界づけられたコンテキスト内で、別の境界づけられたコンテキストのモデルを呼ぶことはない
- コンテキスト外とのやりとりは Published Languag のみでしかしてはいけない。
「支援サブドメイン」と「汎用サブドメイン」の違いは、支援サブドメインが業務的にコアドメインほど重要ではないもの。汎用サブドメインはシステム的には必要だけど、業務には関係ないものって認識でok??
- 業務に全く関係ないってわけではないかも
- 汎用サブドメイン：汎用的に使うもの、別のドメインでも必要となるようなもの
- 支援サブドメイン：コアドメインを支援する上で必須なもの
コアドメインとサブドメインとではコードではどういうふうに分けるのか？ドメインの中でコアとサブがある？
- パッケージで分けてもダメではないけど、あまり分ける必要もないかも
- コアドメインやサブドメインの話は、あくまで、アプリケーションの構成の考えてコアドメインに集中するためのもので、コード上ではそこまで意識する必要はない
ユビキタス言語はドキュメントか何かで管理するもの？
- ドメインモデル図がユビキタス言語を兼ねていることが多いかも
- 特に決まりがあるわけはない
次回
【ミライトデザイン社内勉強会#12】「IDDD本から理解するドメイン駆動設計」輪読会~第3章「コンテキストマップ」~ - Qiita