なんかドメイン駆動設計ってよく聞くけど似たようなやつなんかな？
社内の輪読会にて、CleanArchitectureを読了
CleanArchitecture 達人に学ぶソフトウェアの構造と設計 (日本語)
著：Robert C.Martin
「なんかドメイン駆動設計ってよく聞くけど似たようなやつなんかな？」
と思いいくつか資料を読んだので、備忘録としてまとめます。（ご指摘、感想があればお待ちしております。）
CleanArchitectureは設計思想 vs DDDは開発手法
CleanAritectureはSOLID原則を元にして、
（ビジネスロジックなど）安定度の高いコンポーネントに依存するように依存ルールを決めた設計思想。DDDはお客さん（業務内容の知見者）と共にどうやってビジネスロジックを表したモデルを作るか。ビジネスロジックであるエンティティ(ドメイン層)・ユースケース層の具体的な開発手法
DDDに出てくる用語の具体的な違い
「ドメインエキスパート」「境界づけされたドメイン」「ユビキタス言語」
DDDは業務内容に詳しい人（ドメインエキスパート）と
決定されたスコープ内（境界づけされたドメイン）で、
表記ゆれ・誤解がないよう言語を統一させる（ユビキタス言語を作成する）ことから始まる。
CleanArchitectureと違いコンポーネントの依存ルールだけに話が留まらない。
Entityの概念が異なる。
双方にEntityという用語があるが、
CleanArchitectureでは、Entityはアプリケーションに依存しない最重要ビジネスルール。
一方、DDDでは、同様の概念にドメインがあり、ドメインは（Entity・値オブジェクト・サービスなどで）構成されている。ドメインも同様に最重要ビジネスルールであるが、クリーンアーキテクチャよりは具体的にルールが決まっている。
集約・リポジトリ
CleanArchitectureではEntityは、最重要ビジネスルールとしか書かれていない。例えば、ユーザオブジェクト・ユーザ詳細情報オブジェクト・タスクオブジェクトの3つがあったときに、その関連性についての記述方法はない。
DDDでは、集約という単位でオブジェクトをまとめる。
具体的には、オブジェクトをまとめる＝オブジェクトを変更するタイミングが同じと考え、集約の単位で、集約を一括で変更するリポジトリを作成する。
つまり、リポジトリの単位＝集約の単位である。
ドメイン貧血症
DDDではドメインにビジネスルールを強く書くことが大切であり、
ビジネスルールが抜けたドメインをドメイン貧血症という
参考資料
*「わかる！ドメイン駆動設計 ～もちこちゃんの大冒険～」
https://booth.pm/ja/items/392260
*「ドメイン駆動設計 モデリング/実装ガイド」
https://booth.pm/ja/items/1835632
ゆくゆくはエリック・エヴァンスのDDDも読まなくては。。。