MENU

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

前回のふりかえり

第13章 より深い洞察へ向かうリファクタリング

第4部 戦略的設計

  • システムが複雑になりすぎて個々のオブジェクトのレベルで理解することが出来なくなると、巨大なモデルを扱うためのテクニックが必要になる
  • 第4部では、モデリングプロセスをスケールアップさせて、非常に入り組んだドメインに対応させるための原則を説明する

3つのテーマ

  • コンテキスト
    • 成功するモデルは論理的に一貫しているべき。
    • 明示的に境界付けられたコンテキストを定義し、モデルの摘要を内部に限定することでモデルの質を保つ。
  • 蒸留
    • 注意の対象を適切に絞るための手法。
    • システムにおいて最も付加価値のある部分を目立たせて、巨大なモデルを明確に見えるようにする。
  • 大規模な構造
    • 複雑なモデルに包括的なテーマを与えることで、設計に統一性をもたらす。

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

複数のチームが関わるようなプロジェクトでは、それぞれのグループが異なるモデルを持ち、自由に変更を加えて整合性が取れなくなることがある。

  • モデルには統一性がなければならないが、巨大なシステムのドメインモデルを完全に統一させるのは事実上不可能
    • よって、何を統一すべきか、何を統一しないかを決めて上記の課題を解決する
    • そのためには、さまざまなモデルの境界と関係性をはっきりさせる方法が必要となる

境界付けられたコンテキスト

複数のモデルというのは、どんな巨大なプロジェクトにも存在する。しかし、別々のモデルに基づくコードが組み合わされると、ソフトウェアはバグの温床になる。

  • このような複数のモデルに起因する問題を解決するには、特定のモデルのスコープを定義する
    • モデルが適用されるコンテキスト(境界)を明示的に定義する
    • 境界内は、モデルを一貫性のあるものに保つ

→ そのコンテキスト内で、モデルが論理的に統一された状態を作ることができる。

モデルの違いが認識されていないことを示す兆候

  • 最初は言語の混乱として表れる
    • 重複した概念:実際は同じ概念を表しているモデル要素が2つある
    • 偽同族語:2人が同じ用語を使って、同じことを話しているつもりなのに実は違うものについて話している

→ こうした問題について、これから説明するパターンで対処することができる。

継続的な統合

継続的な統合とは、そのコンテキスト内で行われるすべての作業について、一貫性を保つことで、分派した時にすぐ発見して修正できるようにすること - 多くの人が同一のコンテキストで作業していると、モデルが分裂する傾向が強くなる。それを防ぐために用いる。

  • 継続的な統合は2つのレベルで作用する
    • モデル概念の統合
      • チームメンバ間の絶え間ないコミュニケーションによって実現
      • ユビキタス言語の変更を通して、モデルに対する共有されて見方を練り上げる。
    • 実装の統合
      • システム的なマージ/ビルド/テストのプロセスによって実現
      • モデルの分裂を素早く明らかにする自動テストを用いる

→ 概念の統合によって実装の統合がスムーズになり、実装の統合によってモデルの正当性と一貫性が立証され、分派が明らかにされる。

コンテキスト境界を設定し、その中で一貫したドメインモデルが維持できたら、今度はもっと大きな全体像を把握するために(非OOなレガシーシステムを含む)コンテキスト間の対応関係を明確にする。各コンテキストには、チームのユビキタス言語となるような名前を付ける。それから、あるコンテキストのモデルが別のコンテキストのどのモデルに対応するか、というモデル間の変換マップを考える。システム間連携においては、アプリケーション毎にドメインモデルが全く異なっているのがほとんどなので、コンテキストマップをしっかり作っておくことが重要になる。

コンテキストマップ

コンテキストマップは、コンテキスト同士の関係を明らかにするためのもの。

→ 開発メンバーは、作成中のソフトウェアモデルや設計における概念の再分割に対して、明確な視点を持つ必要がある。そのためにコンテキストマップが必要

  • コンテキストマップは、大体以下のように作成される。
    • プロジェクトで機能しているモデルをそれぞれ識別して、境界づけられたコンテキストを定義する - 境界づけられたコンテキストそれぞれに名前を付け、その名前をユビキタス言語の一部にする
    • どのコンテキストのモデルが別のコンテキストのどのモデルに対応するか(変換されるか)を確認して記述する
    • まず「現在存在する」領域の地図を作成する

→ コンテキストマップに登場するコンテキスト間の関係が、これ以降のページで説明される。

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

  • 理屈としてはすごいわかるけれど、実際にやってみないと自分の中には落とし込めない感じもある。実際のプロダクトでコンテキストの境界引いてみたい。

参考