#book #r2019
## Entity と Value Object
全てのオブジェクトにはビジネスドメインに応じて同一性が必要か必要じゃないかという違いがある。
同一性をなんらかの形で表現したいものは Entity で 値によってその同一性を判断していいものを Value Object と区別する。
通常どんなモデルも同一性を持って Entity として表現したい衝動にかられるが、ソフトウェアは複雑なので複雑性を緩和するためにも、ドメインを強調するためにも同一性や追跡性が必要のないものを Value Objectとして区別すると良い。
## 集約
DDDでもOOPでもオブジェクトが命
オブジェクトには必ずライフサイクルがある、作成されたから破棄されるまで、DBに永続化されたり、要素が変更されたりなど様々な状態遷移をする。
そういったオブジェクトの集約を抽象化する方法として、Factory と Repository がある。
Repositoryは、集約ルートに対するオブジェクトのアクセスを抽象化するもの
- 全てのEntityに用意する必要はない
- つまり集約ルートとその境界をビジネスドメインに沿って判断する必要がある
- Repository : すでに存在しているオブジェクトを再構築する
- Factory : 新規にオブジェクトを作成する
EntityとValue Object は混ぜてはならない
- 例えばデータの検索で「オブジェクトが見つからなければ、新しく生成されたものが返る」というのはEntityを取得しに行ってるのにも関わらずValue Objectが返ってきているので避けた方がよい
## コンテキストとアーキテクチャ
- コンテキストとはあるモデルを使うにあたって想定する前提や意味である。
- 同じモデルでも、アプリケーションによって使われ方が全く異なる場合がある。
- 例えばモバイルアプリでのマルチモジュールで機能ごとにモジュールを切ってる場合には、それぞれは別のコンテキストと呼べるかもしれない。
### Layered Architecture
- モノリスで平べったい場合には、再利用性が落ちる
- またドメインが強調されなくなってしまい知識をコードから得ることが難しくなる。
- 技術的な詳細はそれはそれでレイヤーとして分離してしまい、ドメインに集中するための仕組み
- 
- 
### 境界づけられたコンテキスト
- コンテキストによって境界を切って、そこでのモデルはそのコンテキストに特化したものを使おうというもの。
- 機能ごとに切ったマイクロサービスなどでよく見られる気がする。
- 例えば、認可ではユーザーの権限が気になるが、パーソナライズではユーザーの行動がメインのフォーカスになったりなど
- 多くの場合はこれに沿ってチームが編成されることがある
- 個人的には、チームという枠とプロセスが編成されるだけで、中の人材は流動的でいいと思う
### 共有カーネル
- 境界づけられたコンテキストで作業をしていると最初の方はあるコンテキストに閉じた設計で意図が明確なコードになるだろうけれど、そのうち共有したくなる部分も出てくる。
- これを共有カーネルと呼ぶ。ここはコアドメインが入ってるところかもしれない。
### 腐敗防止層
- コンテキスト外のサービスにはレガシーなものやサードパーティーのものなどコンテキストで使用するモデルの変換が自然にはできないことがある
- とはいえ汚い実装をしてドメインの強調が薄まるのもいやなので、この変換層自体をレイヤーとして分離してうまく外側のシステムとやりとりする層のこと
- 例えば新しいモジュールがレガシーなインフラを使うなどが考えられる
## 気になった章
### 1部 : ドメインモデルを機能させる (1章 ~ 3章)
- DDDの開発思想部分の全てが入ってる感じだった
- この本や [[Clean Code]] や [[A Philosophy of Software Design]] を始め最終的には「お前は何を作ってて、どういうドメインで価値を提供してるんだ？」に尽きることが説明されててよかった
- アーキテクチャとかその後のプラクティスはそれをコードで表現する表現手法にすぎない
- 全人類にこの3章だけでも読んで欲しい章
### 7章 言語を使用する : 応用例
実際にドメインモデリングを導入する感覚を掴める章で 1 ~ 6章 を読んだあとに一通り自分のサービスとかで実践してみると結構学ぶものがありそう
- ドメインを隔離する : アプリケーションの導入
- Entity と Value Object を区別する
- ドメイン関連を設計する
- 集約の境界を定める
- リポジトリを選択する
### 8章 ブレークスルー
- いつも自分は「ドメインの発見」とか「知識の獲得」とか呼んでる部分の話だった
- 実際にこういう自分が何を作ってるのかがはっきりする場面は結構あるのでブレークスルーみたいなたまにしか起きない表現じゃない呼ばれ方がしたかった
## 感想
DDDは、以下で構成されててそれぞれの概念的なところで整理された
- 開発思想
- ドメインを揃えていく必要がある。ドメインエキスパートとの対話が大事
- 戦略的設計
- ドメインモデルをうまく継続性を持たせるための設計 (境界づけられたコンテキストとか共有カーネルとか)
- 戦術的設計
- ドメインを表現するための表現 (集約の抽象化としてのRepositoryパターンなど)
また、巷で「ドメイン駆動設計を採用しています」というのは戦術的設計と [[実践ドメイン駆動設計]] のプラクティス部分を採用しているだけだということも理解できた
- [[実践ドメイン駆動設計]] は、どうやらエリックエバンス本で具体が語られていない設計部分の話であるらしい
レガシーなシステムを作る上でも
- ドメインが何か
- 境界づけられたコンテキストと共有カーネルは何か
あたりはとても参考になる考えであった