MENU

『ドメイン駆動設計』第15章 エヴァンス本 まとめ&感想

DDD

前回のふりかえり

第14章 モデルの整合性を維持する

コンテキストマップで用いられる、コンテキスト間の6種類の関係

  • 共有カーネル
    • モデルの一部を直接共有することで、少ないコストで統合しやすくなる
  • 顧客/供給者の開発チーム
    • 明確に顧客（使う側）と供給者（使われる側）という関係を確立する
  • 順応者
    • 独自のモデルを作らず、あえて上流のドメインモデルに従う
  • 腐敗防止層
    • 相手と自分のシステムの間に隔離(変換)するためのレイヤを設ける
  • 別々の道
    • 二つのシステムを完全に分離し、別々のモデルを使用する
  • 公開ホストサービス
    • あるサブシステムを他の多くのサブシステムと統合しなければならない時に、変換サービスではなく、アクセスするための公開サービスを作成する

第15章 蒸留

  • 蒸留とは、混ざり合ったコンポーネントを分離するプロセスで、価値があって役立つ形式で本質を抽出するためのもの
  • モデルから副次的なものを切り落とし、本当に重要なもの(コアドメイン)に焦点を当てやすくするための技法

→　15章では、広範囲にわたるモデルを識別して、全体としてのドメインモデルを蒸留する方法を見ていく


コアドメインと汎用ドメイン

ドメインをコアドメインと汎用ドメインに分け、巨大なシステムでもモデルの中で最も重要な部分にフォーカスできるようにする

コアドメイン

コアドメインは、システム内で最大の価値を付加すべき場所

  • 巨大なシステムでは、全てを等しく改良することはできないので、優先順位を設定することが必要。コアドメインは他のドメインと比べ最優先される
  • コアドメインを設定するために、下記について留意する
    • コアドメインを見つけて、それを補助する大量のモデル・コードから区別する
    • 最も才能がある人をコアドメインに割り当てる
    • コアドメインもイテレーションの中で進化していく。すぐに作り上げられるものではない

汎用サブドメイン



コアドメインをドキュメント化する

ドメインビジョン声明文

ドメインモデルの重要な側面は、複数のコンテキストにわたることもあるが、それら別々のモデルから共通の側面を読み取れるような構造にはできない。

  • 上記を解決するため、コアドメインとそれがもたらす価値について、1ページ程度の簡単な記述(ドメインがもたらす価値を書いたもの)を用意する
    • ドメインモデルと他を差別化するもの以外は無視して、簡潔にする
    • この声明文は早期に作成し、新しい洞察を得たら改訂する
    • 技術者以外のメンバーも使えるように作成し、誰もがそのドメインの価値を一目でわかるようにする

強調されたコア

ドメインビジョン声明文を導入しても、コアモデルの要素の識別は個人の解釈に委ねられてしまう。チーム全体で同じように解釈できるようにするには、コアドメインがもっと見やすくなる必要がある。

  • コアをわかりやすくするための方法
    • 蒸留ドキュメント
      • 簡潔なドキュメント(3~7ページ程度)を書いて、コアドメインとコアを構成する要素間の主要な相互作用を記述する
      • ドキュメントが確実に維持され、メンバーに読まれるように、ドキュメントは必要最低限に徹する
      • 非技術系のメンバーも理解できるように書く
    • コアにフラグを立てる
      • 作成したドキュメント上で、コアドメインの各要素にマーキングする
      • モデルの主要なリポジトリ内で、コアドメインの各要素にフラグを立てる(コードコメントを書くなどの方法)
      • コアに入るものと、入らないものを開発者が楽に判別できるようにする


コアドメインをより見えやすくする方法

コアドメインから汎用サブドメインを切り離した後、モデルと設計自体を構造的に変更して、コアドメインをさらに見えやすく、扱いやすくする。

凝集されたメカニズム

コアドメインに属するアルゴリズム(どのようにの部分:How)が増えると、そのドメインが何を叶える者なのか(何が:What)がわかりづらくなる。そのような場合は、概念的に凝集したアルゴリズムをドメインから切り離す。

[留意点]

→　上記により、ドメインの他の要素は概念(What)を表現することに集中でき、複雑な課題(How)をフレームワークに委譲できる。


[汎用サブドメインと凝集されたメカニズムの違い]

  • 汎用サブドメイン
    • あくまでドメインモデルである(優先度がコアドメインより低い)
    • ファクトやルール、問題を公式化する
  • 凝集されたメカニズム
    • 処理に焦点を絞っている(モデルではない)
    • モデルの定義に従い、ルールを決定したり、処理を完了させたりする

隔離されたコア

コアドメインに補助的な役割を果たすものが混在していると、コアの発達が妨げられる。補助的な役割を果たすものをコアから分離することが必要となる

[隔離されたコアを作るためのステップ]

  • コアとなるサブドメインを識別する
  • 関連するクラスを新しいモジュールへ移動する
  • リファクタリングして、その概念を直接表現していないデータ/機能を分離する
  • 隔離されたコアのモジュールを、相互作用が単純で伝達力のあるものになるようリファクタリングする
  • 隔離されたコアが完成するまで↑のサイクルを繰り返す


抽象化されたコア

サブドメインの間で大量の相互作用があると、モジュールの分割は事態を余計複雑にしてしまう。その場合は、分割の線を垂直ではなく水平に引くようにする。

  • モデルの最も根本的な概念を識別し、抽象クラスまたはインターフェースに括りだす
    • 抽象的なモデルが、コンポーネント間の相互作用を表現するように設計する
    • この抽象的なモデル全体を、1つのモジュールにまとめる

(本を読んでいてあまりよくわからなかったんだけれども、下記の記事でどんな姿になるのか理解できました)

このモジュール内のモデルは、複数モジュール間の相互作用を抽象化して全体像をまとめたものになる。そして、これが新しい中核のモデルとなる。抽象化によって中核を磨き上げる方法。

参考：[ 技術講座 ] Domain-Driven Designのエッセンス 第3回｜オブジェクトの広場

思ったこと・気になったこと

ここで唐突にドキュメント出てきたなと思った。序盤で出てきた「ドメインモデルを常に変更し続ける」という話と、今回の「コアドメインを蒸留する」という話は全然別のフェーズの話として捉えていいのか、それともドメインモデルの変更の中の一工程が蒸留なのか、頭が混乱中

参考