ドメイン
企業には独自のルールや文化が存在しています。
分析対象となる問題領域(ビジネス課題)、全ての仕組みを理解するにはあまりに大きく複雑なため通常は「コアドメイン」と「サブドメイン」と言う適切なサイズに分割する。
コアドメイン
組織を成功に導くために最も重要なもの。事業的に他と差別化されており最優先で取り組まれる。優秀なメンバーを参画させて積極的に成長させてビジネス的な差別化を図ります。
DDDで開発を行う場合はそれが本当にコアドメインなのかはチームメンバーで議論をしてしっかり把握する必要があります。
サブドメイン
コアドメインほど重要じゃない業務です。
なお、当事者によってはコアとサブが入れ替わるので注意です。(例えば、EC構築とERPの事業があった場合に、EC構築メンバーからはERPはサブですし、ERPメンバーから見たらEC構築事業はサブドメインになります。)
支援サブドメイン
業務的に特別だが、コアドメインほど重要じゃない。コアドメインの支援を行う独自機能など。
汎用サブドメイン
業務的に特別じゃないが、全体として必要(認証系、外部ERPなど、極端な話交換されたとしても差支えがない機能のことです。)
境界づけられたコンテキスト
戦略的/業務的なドメインの問題を技術的なソリューションで解決する。(解決領域)
巨大なモデルを構築しないようにユビキタス言語の境界に従いコンテキストを複数に分割。(要は、一つの単語が複数の意味を持たないように適切にドメインを分割する)
「一つのコアドメイン(もしくはサブドメイン)」に一つの「境界づけられたコンテキスト」が対応している状態が最適だとされています。現実としては、「複数のドメイン」に「一つの境界づけられたコンテキスト」が対応しているケースが多いようです。
一つの境界づけられたコンテキストは一つのチームで担当します。ドメインエキスパートは一人置いて一人のエキスパートがユビキタス言語を定義してできるだけシンプルなモデルを構築します。
例
「商品」と言う単語は、システムの状態によって複数の表現をします。
取扱状態 | 呼び方 |
---|---|
予約中 | 入荷待ち |
入荷時 | 着荷品 |
発売中 | 在庫中 |
販売後 | 出庫品 |
トラブル発生時 | 不良品 |
販売されている状態なら「在庫品」ですし、販売後は「出庫品」などと表現します。
一つの単語が複数の意味を持たないように適切にプログラムを分割して複雑化を防ぎます。
設計指針
境界づけられたコンテキストを設計する場合、アーキテクチャ、タスク分割、成果物などの影響は受けないようにする。
この記事へのコメントはありません。