第一章 DDDへの誘い

p8

さらにまずいのが、ソフトウェア開発の際の技術的アプローチによっては、事業の進めかたを間違った方向に変えてしまうことだ。状況は違うが、企業資源計画（ERP）ソフトウェアを導入するために、組織の業務の流れをERPソフトの機能に合わせて変更してしまうという話もよく聞く、ERPの総保有コストは、単にライセンンス価格や保守料金だけでは算出できない。そういった目に見えるコストよりも、業務体系の見直しによる混乱の方が、よっぽど高くつく。

今のプロジェクトでも似たようなことがあるな

• p13 インピーダンスミスマッチとは？

  • インピーダンスミスマッチについて本気出して考えてみた - 酔いどれ設計ナイト2019

• null安全について

  • null安全でない言語は、もはやレガシー言語だ

第2章 ドメイン、サブドメイン、境界づけられたコンテキスト

ドメインとは

• 広い意味で言うと組織が行う事業やそれを取り巻く世界のこと
• 単にコアとなる一部分やそれを支援する一部分だけを指すこともある-> コアドメイン、サブドメイン
• DDDの最終目標は全体をカバーする全部入りのモデルを一つだけ作るのではない。複数のサブドメインを組み合わせて、組織の全てのドメインを作り上げることである
• ドメインモデルを開発するということは、事業のドメイン全体の中で特定の部分にだけ注目するための一つの方法

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

• 今稼働中のシステムのほとんどはDDD以外の方法で作られたものである。ありがちな状況として、サブシステムの数が本来あるべき姿より少なすぎて、一つのサブシステムで多くの業務機能を受け持ち過ぎている可能性がある
• (Eコマースの例) 例えば商品カタログ・注文・請求・発送というモデルが単一のEコマースモデルにまとまっていると、それぞれの論理モデルに新しいフィーチャーを追加しようとしたときに、お互いの関心ごとが衝突すれば、モデルの変更の障害になってしまう
• DDDの戦略的設計ツールを使えば、上記のような複雑性にある程度は立ち向かえる
• サブドメインは常に適切なサイズと機能のモデルに分割されているとは限らない。業務のソリューションに欠かせないアルゴリズムをまとめただけのサブドメインもあり得る。そのてのサブドメインはモジュールとしてコアから分離すればいい。
• DDDを実践する際には個々の境界づけられたコンテキストについて、そのドメインモデルで使われる全ての用語の意味を理解しようと心がける。特に言葉の境界を気にしよう。
• 一つの境界づけられたコンテキストが必ずしも一つのサブドメインだけで成り立つとは限らない

コアドメインに注目する

• 自分たちのドメインやサブドメイン、境界つけられたコンテキストに沿った図を描こう
• コアドメインとはサブドメインの中でも組織を成功に導くために最も重要であり最優先で取り組むべき事業を成功させるために不可欠なもの
• 支援サブドメインとは業務に不可欠な内容であるがまだコアドメインとは言えないようなモデルのこと
• 汎用サブドメインとは業務上特別なことを特に何もしてなくても、ソリューション全体として必要なドメイン
• 支援サブドメインであるか汎用サブドメインであるかはそれほど重要ではなく卓越する必要はない。はっきりした利益を教務にもたらすコアドメインについて卓越が必要。

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

• ドメインは問題空間と解決空間を持っている
• 問題空間
  • 解決すべきビジネス戦略上の課題を浮き彫りにするもの
  • ドメインの一部であり新しいコアドメインを生み出すための開発を要するところ
  • つまりコアドメインとそこから使う必要があるサブドメインを合わせたもの
• 解決空間
  • ソフトウェアをどのように実装してその課題を解決するかに注目するもの
  • 境界づけられたコンテキストのことで、特定のソフトウェアモデルの集合となる
  • 境界づけられたコンテキストは特定のソリューションを表すものであり何らかのソリューションをソフトウェアとして具現化する

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

境界づけられたコンテキストは明示的な境界であり言語的な境界である

• 極端な例
  • 同じ「アカウント」という用語でも銀行取引アカウントでは口座を表し、文学コンテキストでは報告書を表す。
  • それぞれのアカウントの特徴は名前だけでは区別できない。区別するにはそれぞれが属する概念的なコンテナ、つまり境界づけられたコンテキストに注目する。
  • （感想）当たり前だけど確かに普段使っている言葉でも文脈によって意味が異なるということはよくある
• 異なるコンテキストで同名のオブジェクトについて丁寧に区別する名前をつける必要はない
  • 当座預金コンテキストでも普通預金コンテキストでも単に「口座」と名付けて構わない。「当座預金口座」と名付ける必要はない。境界づけられたコンテキストが微妙な意味の違いを区別する。
• 境界づけられたコンテキストはモデルだけを扱えないということではない。システムやアプリケーション、あるいは業務サービスなどを区切るために使うことも多い。
• p 63 利口なUIアンチパターンとは
  • Smart UI パターンが再評価される世界

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

• ひとつの境界づけられたコンテキストの中に含まれるモジュール・集約・イベント・サービスの数に正解はない。ユビキタス言語の全貌を完全に表現できるだけの大きさでなければいけない。
• 取捨選択には正しい判断が必要となる。コンテキストマップのようなツールを使えばチームの判断力を磨く助けになるだろう。
• いつだってドメインモデルを完璧に磨き上げることはできず、どこかに不満を残してしまう。
• モデルに何らかの概念を追加したり概念を削除したり、何かの概念の振る舞いや他との協調方法を変更したりすることを強いられたりと何度も繰り返し問題に直面することになる。
• DDDの原則に従うことで何がモデルに属して何がモデルに属さないのかをきちんと考察できるようになる。
• 境界づけられたコンテキストのサイズを間違えて作ってしまう原因
  • ユビキタス言語ではなくアーキテクチャ に影響を受けてしまう
    • プラットフォームやフレームワークなどのインフラストラクチャが、境界づけられたコンテキストを考えるときに影響を及ぼしてしまい、言語的な境界ではなく技術的な境界を考えてしまうということ
  • チームの開発要員へのタスクの割り当てのことを考慮してしまう
    • PMは開発者に渡すタスクを最小限にした方がやりやすいと考えるかもしれないが、タスクの割り当てのために協会を定めるというのは言語をベースに文脈的なモデリングをするという指針に反する。開発要員の管理のしやすさを考慮して偽の境界を定める必要は一切ない。

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

• 単一の境界づけられたコンテキストの作業は単一のチームが受け持つべき
• 単一の境界づけられたコンテキストに複数のチームを割り当てると、それぞれのチームが自分たちの解釈でユビキタス言語を定義してしまい、ユビキタス言語があやふやなものになってしまう

第4章 アーキテクチャ

• ソフトウェアの品質についての実際の要求が、どのアーキテクチャスタイルやパターンを採用するかの原動力になるべきだ。パターンの過剰な適用を避けることは重要。何かしらのアーキテクチャを利用する時は正当な理由付けをできるようしておく必要がある。何らかのアーキテクチャやパターンなりの採用を正当化するには、ユースケース、ユーザーストーリー、ドメインモデルに固有のシナリオなどの機能要件がわかる必要がある。

4.2 レイヤ（レイヤードアーキテクチャのざっくりとした説明）

• ユーザーインターフェースレイヤには、ドメインロジックを含めていけない。ユーザーインターフェースにおけるバリデーションは粗いものにとどめて、業務に関する深い知識はモデルだけで表現するようにしたい
• ユーザーインターフェースコンポーネントがドメインモデルのオブジェクトを使う場合は、単にそのデータをレンダリングするだけにとどめておくのが一般的。プレゼンテーションモデル（14章）が使える。

依存関係逆転の原則 （Robert C.Martin）

上位のモジュールは下位のモジュールに依存してはならない。どちらのモジュールも、抽象に依存すべきである。抽象は、実装の詳細に依存すべきではない。実装の詳細が、抽象に依存すべきである。

4.3 ヘキサゴナルアーキテクチャ

Alistair Cockburnがまとめた対称性を生み出すためのスタイル。お互いが全く異なるさまざまなクライアントが、同じ足場を使ってシステム対話できるようにする。

ポートとアダプター

• さまざまな型のクライアントが、それぞれ自分用のアダプターを持っていて、それがアプリケーションAPI（内部）に合わせた形式に入力を変換する。
• アプリケーションの境界はユースケースの境界でもあり、ユースケースを作るときにはアプリケーションの機能要件を基準にするのでクライアントの種類は関係ない。
• 出力側のアダプターとしては、リレーショナルデータベース、ドキュメントストアなどのぞれぞれの実装を用意することができる。
• また利点としてテスト用のアダプターを簡単に作れるので、アプリケーション全体とドメインモデルの設計やテストをクライアントやストレージが確定しないうちから行うことができる。

4.5 REST

4.6 CQRS