実践ドメイン駆動設計 - 第2章 ドメイン、サブドメイン、境界づけられたコンテキスト

実践ドメイン駆動設計 第2章のまとめです。

2.8 全体像

サブドメインと境界づけられたコンテキストのはたらき

  • オンライン販売を例に考える
    • 本書の図 2-1 を参照
      • 本来分割すべきドメインモデルが、単⼀のソフトウェアモデルになってしまっている (Eコマースシステム)
    • DDD の戦略的設計ツールを使えば、コアドメイン、サブドメイン、境界づけられたコンテキストで分割・整理できる

コアドメインに注⽬する

2.9 なぜそれほどまでに戦略的設計を重視するのか

  • コラボレーションプロジェクトチームの例を考える
    • 問題
      • 開発を進めるうちに、コラボレーションというモデルの中にパーミッションなどのモデルが紛れ込んでしまった
      • しかし、本来パーミッションはコラボレーションとは何の関係もなく、コラボレーションのユビキタス⾔語にも含まれない
      • パーミッションの挙動が変わると、コラボレーションモデルの他の部分まで影響が波及する状態になってしまう
    • DDD としての解決策
      • コラボレーションツールで重要な、フォーラムやカレンダーなどの本当にコアの概念だけをまとめた「コンテキスト」を切り出す
        • コラボレーションコンテキスト
      • パーミッションは、セキュリティコンテキストとして別のコンテキストに切り出す

2.10 実世界におけるドメインとサブドメイン

問題空間

  • 解決すべきビジネス戦略上の課題を浮き彫りにする
    • 課題のうち、ビジネス戦略上特に重要な問題群がコアドメインと成す
  • 問題空間の評価には、コアドメインと、サブドメインも見る必要がある

解決空間

  • ソフトウェアをどのように実装してその課題を解決するかに注⽬する
  • 解決空間 = 境界づけられたコンテキスト
  • 境界づけられたコンテキスト
    • 例えば、
      • 特定のソリューションを表すもの
      • 特定のソリューションを具現化したビュー
      • 特定のソフトウェアモデルの集合
  • 境界づけられたコンテキストを⽤いて、何らかのソリューションをソフトウェアとして具現化する

問題空間と解決空間

  • 各サブドメインを、境界づけられたコンテキストと⼀対⼀で対応させるのが望ましいゴール
    • しかし実際は難しいので、アセスメントビューを使う (これ以上詳しい説明がなかった)
  • ERP (Enterprise Resource Planning) アプリケーションを例として考えてみる
    • 会計、プロジェクト管理、製造などの日々の業務を管理するために組織が使用するシステムおよびソフトウェアパッケージ

評価

  • 問題空間 (ドメイン) の評価のための質問
    • 本書の質問リストを参照
    • コアドメインのビジョンやゴールを理解せず、それを⽀援するためのドメインの範囲も把握できていないようなら、戦略的な利益を得ることなどできないし、落とし⽳を回避することもできない
    • 問題空間の評価は概念レベルのものでよいが、全体を通して⾏う
  • 解決空間 (境界づけられたコンテキスト) の評価のための質問
    • 本書の質問リストを参照
    • 既存システムやテクノロジーの影響を受ける

2.11 境界づけられたコンテキストの意味を知る

  • 境界づけられたコンテキスト
    • コンテキストの明⽰的な境界
    • ドメインモデルがどこに属するのかを表すもの
    • プロジェクトの成果物に何か制限をかけるようなものではない
    • コンポーネントやドキュメント、図などを表すものでもない
  • ドメインモデル
    • ユビキタス⾔語をソフトウェアモデルとして表したもの
  • なぜ "境界" が必要なのか?
    • 各モデルの内部的な概念やプロパティ・操作がそれぞれ特別な意味を持つから
    • 異なる⼆つのモデルが、同じ、あるいはよく似た名前のオブジェクトを違う意味で使っていることが多い
      • ⼆つのモデルを明確に境界づけておくことで、それぞれのコンテキストにおける意味合いをはっきりさせる
    • したがって、境界づけられたコンテキストは主として "⾔語的な境界" となる
  • 巨大モデルの誘惑
    • あらゆる名称が唯⼀の意味しかもたないように、全部⼊りの巨⼤なモデルを作ってしまうという誘惑がある
    • しかし、あらゆる概念に対してステークホルダー全員が納得するような共通の意味付けをすることは事実上不可能
    • 統⼀などできないという前提の上で、境界づけられたコンテキストを使って個々のドメインを個別に描いていく

コンテキスト

  • 文脈
  • 例えば、同じ「アカウント」という⽤語でも、銀⾏取引コンテキスト (口座) と⽂学コンテキスト (報告書) とでは意味合いがまったく異なる
  • 実世界におけるコンテキスト
    • 実際の業務でありがちなのは、似ているけれども微妙に意味が違うという状況
    • なぜなら、各チームがそれぞれのコンテキストで選んだ名前は、そのユビキタス⾔語を念頭に置いて考えられているものだから
  • 「アカウント」の例をもう少し
    • 「当座預⾦⼝座」と「普通預⾦⼝座」の銀⾏取引コンテキストを考えてみる
      • 当座預⾦コンテキストで使うオブジェクトに「当座預⾦⼝座」、普通預⾦コンテキストで使うオブジェクトに「普通預⾦⼝座」などとご丁寧に名づける必要はなく、単に「⼝座」と名づけられる
      • それぞれの境界づけられたコンテキストが、微妙な意味の違いを区別する
      • 名前を同一にしなければいけないという決まりがあるわけではないので、チームが判断すればよい
  • 境界づけられたコンテキスト間でのマッピング
    • 通常は通常はオブジェクトのインスタンスを境界の外で使うことはないが、状態の一部を共有することがあるかもしれない
      • あまり詳しい説明はなかった
  • 同一モデルの中の複数のコンテキスト
    • 出版社の業務モデルの例
      • 書籍の起案 -> 執筆と編集のプロセス管理 -> 装丁や挿絵をデザイン -> 他の言語に翻訳 -> 宣伝　-> 出荷
      • これらを統一的に扱うモデルを使おうとしてしまうと混乱する
      • 段階ごとに「書籍」の定義すら変わってくる
      • 実際には、書籍オブジェクトにはおそらく識別⼦があって、それをコンテキスト間で共有するのだろう
    • コラボレーションチームの例
      • コラボレーションコンテキストのドメインエキスパートは、コラボレーション機能の利⽤者のことを「パーミッションを持つユーザー」とは定義せず、利⽤者が演ずる役割 (投稿者・所有者・参加者・モデレーター) と定義した
      • 認証・アクセスコンテキストでは、ユーザーオブジェクトが各個⼈のユーザー名と認証・アクセス情報を保持する
    • 重要なのは、"異なる概念やオブジェクトが、同じものであるともいえるし違うものだともいえるということで、その違いは、どの境界づけられたコンテキストで⾒るかによるということ"

モデル以外のものを扱う余地

  • 境界づけられたコンテキストは、ドメインモデルだけを扱うものというわけでなはい
    • システムやアプリケーション、あるいは業務サービスなどを区切るためにも使われる
  • 利口なUI アンチパターン
    • ビジネスロジックやデータアクセスのコードが、UI のコードと一緒になってしまっている状態
    • すべての処理が UI の中で行なわれるので「利口な」UI と呼ばれる

境界づけられたコンテキストの⼤きさ

  • 要点
    • 境界づけられたコンテキストは、ユビキタス⾔語の全貌を完全に表現できるだけの⼤きさでなければならない
    • ユビキタス言語に存在しない概念は考慮に入れない
    • 本来コアドメインに属すべき概念を、間違って外に出してしまわないように気をつけよう
  • ドメインモデルの変更
    • イテレーションのたびに、私たちはモデルに関する仮定と戦うことになる
      • モデルに何らかの概念を追加したり削除したりする
    • ここでのポイントは、何度も繰り返し問題に直⾯するということ
    • DDD の原則に従っていれば、何がモデルに属して何がモデルに属さないのかをきちんと考察できるようになる!
  • ドメインモデルの美しい⾳⾊
    • 観念的すぎてわからん
  • 境界づけられたコンテキストのサイズを間違えて作ってしまう原因
    • ユビキタス⾔語ではないものに影響を受けている
      • アーキテクチャ、インフラ、チーム開発要員へのタスクの割り当て
      • 偽のコンテキストを作ってアーキテクチャ的な問題や開発者の問題に対応してしまうと、⾔語が分断されて、表現⼒を失ってしまう (ドメインモデルの変更に耐えられなくなる)
  • 適切なサイズの境界づけられたコンテキストを作る時の留意点
    • コアドメインに注⽬
    • 単⼀の境界づけられたコンテキストに⾃然におさまる概念だけに注⽬する
    • ドメインエキスパートの⽤語に従う
    • 単⼀のモデルにうまくおさまるようなコンポーネントを⾒つけだし、境界づけられたコンテキストに含める
    • 先⾛って⼩さくしない

技術的なコンポーネントとの協調

  • 境界づけられたコンテキストを、技術的コンポーネントの観点で考えることは特に問題はないが、技術的コンポーネントがコンテキストを定めるのではないことに注意する
  • Java での例
    • 境界づけられたコンテキスト
      • com.mycompany.optimalpurchasing
    • 責務による分割
      • com.mycompany.optimalpurchasing.presentation
      • com.mycompany.optimalpurchasing.application
      • com.mycompany.optimalpurchasing.domain.model
      • com.mycompany.optimalpurchasing.infrastructure
    • このようにモジュール分割したとしても、単⼀の境界づけられたコンテキストの作業は単⼀のチームが受け持つべき
      • 明確に境界づけられたコンテキストで作られたユビキタス⾔語にチームを注⼒させるため
    • Java だと、境界づけられたコンテキストをひとつの JAR にまとめられる

2.12 サンプルのコンテキスト

  • 現実世界では、あらゆるプロジェクトに、境界づけられたコンテキストが複数存在するため、それらの統合が重要となる
  • 例として、コラボレーションツール (G Suite や Confluence みたいなやつ) について、セキュリティや権限の情報をコラボレーションモデルに組み込んでしまうという間違いを犯してしまった、ということを考える
    • "まさにコアビジネスロジックのど真ん中で、開発者がクライアントの権限をチェックしてからリクエストを処理していたのだ。"
  • どう改善するか?
    • コンテキストマップを使い、現在の問題点を整理する
      • [Evans] の「第4部：戦略的設計」で紹介されている? (未確認)
      • これにより、現在の窮状を議論することで、建設的な分析で解決策を考えられるようになった
    • 隔離されたコア [Evans] を⽬指す
      • コラボレーションコンテキストの中にあるセキュリティや権限がらみの箇所を徹底的に調べ上げ、認証やアクセス管理のコンポーネントを切り離す
        • 具体的には、"セキュリティや権限に関するすべてのクラスをモジュールに隔離して、アプリケーションサービスのクライアントがセキュリティや権限をチェックするときには、コアドメインを呼ぶ前にそれらのオブジェクトを使わせるようにした"
      • "隔離されたコアを切り出すタイミングは、システムにとって重要な、巨⼤な境界づけられたコンテキストがあり、モデルの本質的な部分が⼤量の補助的な機能のせいでわかりにくくなってきた時である"
  • 境界づけられたコンテキストを⼩さくするべく、いくつかの⼩さなコンテキストを切り出すことも考えられるが、これは良くない
    • コラボレーションの機能ごとに分けると、たとえばフォーラムやカレンダーなど数 10 のモデルに分離するだろう
    • すると、ユビキタス⾔語のモデリングの原則に反する挙動になる
    • 境界づけられたコンテキストごとにユビキタス言語が分離されることになるが、実質はほとんど同等なユビキタス言語が複数存在することになる