FLINTERS Engineer's Blog

FLINTERSのエンジニアによる技術ブログ

エリック・エヴァンスのドメイン駆動設計 読書メモ5

元記事はこちら

読書メモ4 の続き。 引き続き第15章を読みました。だんだん読むペースが落ちてきている。

第15章 蒸留

モデルから本質的なものを抽出し、価値を高めるプロセスのこと。

コアドメイン

システムが大きくなると、コンポーネントが増え、本質が見えづらくなる。 開発者は本質が見えないと変更しづらい。変更をスムーズに行うには特定領域を熟知する必要がある。

複数あるサブドメインの中でも中心的なものをコアドメインと呼ぶ。 コアドメインを周辺領域から区別する手段を講じる。 コアドメインは小さくする。 コアドメインはアプリケーションを差別化するビジネス資産であるため、最も才能のある開発者に担当させ、しなやかな設計を達成する。

コアドメインは1つとは限らない。

ドメインに対する関心が強く、長い間ドメインとともに歩もうと考えている開発者たちと、ドメインエキスパートのチームでコアドメインを作成する。 ドメイン知識は蓄積する必要があるため、コアドメインの作成を外部に頼むことや、コアドメインを購入することは実践的ではない。

汎用サブドメイン

本質的ではないが、汎用的であり、確実にドメインモデルの一部を構成するものは汎用ドメインとして切り出す。 凝集度の高い部分を識別し、汎用的なモデルとして別モジュールにすることで汎用サブドメインを抽出できる。

汎用サブドメインよりコアドメインの開発を優先するべきだ。

汎用サブドメインは買ってくることや、公開されているモデルの採用を検討するべきだ。 外部に頼むのも選択肢に入る。

汎用サブドメインの再利用性を気にしすぎないこと。 再利用性を実現するには投資が必要だが、優先的にコアドメインに投資するべきだ。

アジャイルではリスクを早期に減らしていくが、コアドメインモデリングのリスクは低く見積もられがちなので注意。

ドメインビジョン声明文

コアドメインとその価値についての簡潔な(約1ページ)記述。 自然言語で記述する。コアドメインについての意識を高めるのに役立つ。

  • 差別化要素ではないものは無視する
    • UI、外部システムインタフェース、使用技術、プロジェクト運営方法などはドメインビジョン声明文に入るべきではない
  • スコープを広げすぎない
  • プロジェクト早期に作る
  • 新しい洞察を得たら改定する

強調されたコア

コアドメインをコード上で切り離す行為。

コアに対する認識が深まっていない状態で、いきなり切り離そうとするのは実用的ではない。 認識を深めるテクニックとして次の2つがある。

  • 蒸留ドキュメント
    • 本質的な概念オブジェクト群とその間の主要な相互作用だけを記載したドキュメント
    • ドキュメントの維持や理解にかかるコスト、複雑さを増やさないために、コアの境界を説明する最小限のドキュメントとするのがよい
  • コアにフラグを立てる
    • 既存ドキュメントのコア部分にフラグ(マーク)をつける

蒸留ドキュメントはコードとモデルを変更する際の指針として使える。

凝集されたメカニズム

what が how に侵食されて複雑さを増大させている場合、凝集された how (メカニズム) を切り分けることで、コアを際立たせることができる。

汎用サブドメインは表現力をもつモデルであり、チームの視点を反映している。メカニズムは処理を担当する。

隔離されたコア

モデルから汎用サブドメインやメカニズムを抽出していく方法では、コアは抽出の抜け殻のほうに存在する。こちらはコアを抽出する手法。

重要で巨大な境界づけられたコンテキストがあり、補助機能によって本質がわかりづらいときには、コアを隔離するべきだ。

隔離されたコアで作業すると、本質に対する洞察が深まることがある。洞察はチームで共有しする。個人で行動することはできない。

抽象化されたコア

多態的なインタフェースがドメインの概念と一致するときには、抽象クラスやインタフェースでの抽出を試みる価値がある。 抽出したものは別のモジュールにまとめ、実装クラスをサブドメイン置く。

リファクタリング対象の選び方

リファクタリングの費用対効果を上げるには

  1. 困ったことがおきて、それがコアドメインに一部でも関係するものであったなら、歯を食いしばってやる
  2. 自由があるときは、コアドメインのより適切なくくりだし、コアの隔離、汎用サブドメインの抽出をやると良い

感想

前章(第14章)はコンテキストの境界を明らかにする方法を探った。本章(第15章)はドメインを分割して理解しやすくしようという試み。人間の認識力の限界を超えないように、如何に分割統治するか、という方法論だ。

IDDD本の第2章「ドメイン」「サブドメイン」「境界づけられたコンテキスト」を読み解くによれば、境界づけられたコンテキストは解決領域であり、コアドメインサブドメインは問題領域に位置づけられる。この分類によれば本章は問題分析の方法について述べていることになる。実際には、コアドメインサブドメインに対応するモデルや実装のリファクタリングに対する言及があるため、問題領域と解決領域の両方にまたがった言及というふうに理解している。サブドメインが発見されることによりサブ言語が定義され、サブコンテキストが発生するのだろう(読み間違ってたら教えて)。

コアドメインこそがビジネスの根幹だが、それをやりたがる熟練開発者は少ない、という点は興味深い。開発者さん、ビジネスに敏感になろう。

汎用サブドメインを認識することで外部調達の可能性が開ける点は認識しておきたい。買ってこれるなら買ってきたほうがいいよね。

残り2章。