DDDを学ぶ際に参考にした資料・記事まとめ

## (簡単に)DDDとは

- Domain-driven design(ドメイン駆動設計)
- ドメインの概念を正確に反映したソフトウェアをつくる為の開発手法
- DDDの3本柱
    - コアドメイン
    - ユビキタス言語
    - モデル駆動設計

## DDD Quickly(日本語版)

https://www.infoq.com/jp/minibooks/domain-driven-design-quickly/

- DDD Quicklyは、DDDを要約したもので、ページ数は80ページほど
- なので、この本の目的は「DDDを詳しく理解すること」ではなく、「基礎を素早く学ぶこと」


<details><summary>要約</summary><div>

### イントロ
- DDD Quickly自体がDDDの要約
- この本の目的
    - ~~DDDを詳しく理解すること~~ => 基礎を素早く学ぶこと

### 1 ドメイン駆動設計とは何か
**ドメイン -> モデル**

- ドメインのモデルのコードを読むだけでドメイン、ドメインの業務について多くのことを理解できる
- ドメインの複雑さに対処することができる
- モデルを表現したものがあれば、コードの設計を始められる

**モデル化するには**

- ドメインの専門家の持つ知識から
    - モデルを構築するために重要となる重要な部分を抜き出し一般化する必要がある
    - また、扱いやすい形式に変換しなければならない
- 早めにプロトタイプを作成、動作確認し、ドメインの専門家からフィードバックをもらう

### 2 ユビキタス言語
**ユビキタス言語とは**

- ドメインモデルに基づく共通言語
    - 言語を変更したらモデルも変更しなくてはならなくなるようにドメインモデルと言語が強く結びつく
- 使うことで、設計のすべての部分が結びつき、設計チームが効率よく作業するための前提が生まれる
- ドメインの専門家とのコミュニケーションのやり方の違いを克服するためのもの

### 3 モデル駆動設計
**モデル -> コード**

- ~~分析モデル~~ =>ドメインモデリングと設計を密接にするのが良い方法
    - 開発者も議論に巻き込む

**ドメインモデルを正しく設計に反映させるには**

- 設計との対応関係が明確なモデルであること
- より自然にソフトウェアを実装できるモデルであること

**モデル駆動設計の基本要素**

- **レイヤアーキテクチャ(Layered Architecture)**
    - **ユーザインターフェイスレイヤ(プレゼンテーションレイヤ)**
        - ユーザに対して情報を表示し、ユーザの命令を解釈する
    - **アプリケーションレイヤ**
        - アプリケーションの活動を調整する薄いレイヤ
    - **ドメインレイヤ**
        - ドメインモデルを表現することに集中
    - **インフラストラクチャレイヤ**
        - 他のすべてのレイヤを補助するライブラリとして働く
- **エンティティ(オブジェクト)(Entities)**
    - 一意性を持つものとして分類でき、常に同一であり続けるオブジェクトのこと
- **バリューオブジェクト(Value Objects)**
    - 一意性を保証する必要がない、ドメインの一つの側面を表現するためのオブジェクト
    - エンティティオブジェクトにしなかったオブジェクト
- **サービス(Services)**
    - 本来はどのオブジェクトにも属さない振る舞いを定義したもの
    - 操作を実行するオブジェクトや操作の対象となるオブジェクトと関係する
- **モジュール(Modules)**
    - ドメインモデルを複数のモジュールの集まりとして構築する
    - 関係する概念やタスクを組織して複雑性を低減する方法
- **モデリングの難題に対処するパターン**
    - **アグリゲート(Aggregates)**
        - オブジェクトの所有権と境界を定義するのに使うパターン
        - 関連するオブジェクトの集まりで、データの変更について一括で扱うことができる
    - **ファクトリ(Factories)**
        - オブジェクト作成の複雑な操作をカプセル化するのに役立つパターン
    - **リポジトリ(Repositories)**
        - オブジェクトの参照を取得するのに必要なロジックをすべてカプセル化するためのパターン

### 4 リファクタリングのためにさらに深い洞察
**リファクタリング**

- コードに対するリファクタリング
    - パターンを作れる
- ドメインとそのモデルに対するリファクタリング
    - パターンを作れない
    - 深い思慮、洞察、経験、直感による

### 5 モデルの完全性を維持する
**モデルの完全性を維持するための方法論**

- **コンテキスト境界(Bounded Context)**
    - **継続的な統合(Continuous Integration)**
    - **コンテキストマップ(Context Map)**
        - **共有カーネル(Shared Kernel)**
        - **カスタマーサプライヤ(Customer-Supplier)**
        - **順応者(Conformist)**
        - **防腐レイヤ(Anticorruption Layer)**
        - **「別々の道」パターン**
        - **公開ホストサービス(Open Host Service)**

**蒸留(Distillation)**
- ドメインの中核を表すコアドメインを定義し、得られた副産物はドメインの他の部分を構成する一般的なサブドメインとする

</div></details>

## DDD Quickly

https://www.infoq.com/minibooks/domain-driven-design-quickly/

- 日本が不自然だったり、図が一部見づらかったりする箇所はこちらで補完

## Scalaコードでわかった気になるDDD

https://labs.gree.jp/blog/2013/12/9354/

- Scalaのコードを例に出して説明されている
- Entity, Aggregateあたりの理解の助けになった

## ドメイン駆動設計は何を解決しようとしているのか[DDD]

https://qiita.com/little_hand_s/items/721afcbc555444663247

- 短くまとまっていて良かったです

## 「実践ドメイン駆動設計」を読んだので、実際にDDDで設計して作ってみた！

https://qiita.com/APPLE4869/items/d210ddc2cb1bfeea9338

- 全部読めてない。。。(ものすごく長いです)

## 今後の展望

- 理解を深めていくためにも「エリック・エヴァンスのドメイン駆動設計」or「実践ドメイン駆動設計」を読みたい
- 最終的にはDDDで設計までやってみたい
- DDDとオブジェクト指向、マイクロサービスとの関係性みたいなものを正しく理解したい