こんにちは！
この前、ドメイン駆動設計の本を読んだので、内容を振り返ってみようと思います。
ドメイン駆動設計とは
ドメイン駆動設計（DDD）は、ビジネスの中身やルールをしっかり理解して、それをそのままコードにする考え方です。
「この仕事ってどういう流れ？」「どんなルールがあるの？」といった業務の仕組み（ドメイン）をちゃんと捉えて、プログラムにも反映させます。
値オブジェクトとエンティティの違い
DDDにおいて、モデルを構成する基本要素の1つが「値オブジェクト」と「エンティティ」です。
この2つはよく似ているようで、使い分けが非常に重要です。
値オブジェクト（Value Object）
一言でいうと、「中身がすべて同じなら、どれも同じとみなせるもの」です。
例：
- 100円玉が2枚あったら、どちらも同じ「100円」として扱えます。
- 「東京都新宿区」という住所が2つあっても、それは同じ場所を指します。
名前やIDで区別する必要はなく、「ただの情報」として扱います。
エンティティ（Entity）
一言でいうと、「見た目や内容が似ていても、1つ1つが別物として区別されるもの」です。
例：
- 同じ名前の人が2人いても、それぞれ別人として扱います。
- 同じ商品を2回注文しても、それぞれの注文は別の扱いになります。
内容が同じでも、「それがどれか」を識別する必要があります。識別のためにIDなどを持ちます。
比較表
| 種類 | 値オブジェクト | エンティティ |
|---|---|---|
| 識別方法 | 値がすべて同じなら同一とみなす | 一意のIDなどで識別 |
| 特徴 | 不変（immutable） | 状態が変わることがある |
| 例 | 金額（Money）、住所、メールアドレス | ユーザー、注文、商品（IDあり） |
サービス（Service）
サービスは、ドメインの中で重要な処理のうち、エンティティや値オブジェクトに属さないようなロジックを担当します。
どういう役割？
エンティティや値オブジェクトには、それぞれ責任があります。
でも、中には「どのクラスにも当てはまらない処理」が出てくることがあります。
たとえば：
- 注文に対して割引金額を計算する処理
- 商品の在庫が十分にあるかチェックする処理
こういったロジックを無理にエンティティに入れるよりも、**専用のクラス（サービス）に分けて整理したほうがスッキリします。
リポジトリ（Repository）
リポジトリは、エンティティを保存・取得するための「窓口」です。
アプリケーションとデータベースのやり取りを仲介する役割を持ちます。
どういう役割？
たとえば、注文（Order）をデータベースから取得したり、保存したりするとき。
これをアプリケーション内で直接SQLで書いてしまうと、ドメインロジックと混在してごちゃごちゃになってしまいます。
そこで、データの出し入れはすべてリポジトリにまかせることで、コードをスッキリ保ちます。
おわりに
DDDの用語や概念は最初少し取っつきにくいですが、業務の流れやルールをしっかりコードに落とし込めるので、大規模開発やチーム開発で特に力を発揮します。
これからも少しずつ理解を深めていこうと思います！
今度実践編ということで何か作ってみます～