# DDD

## ドメイン
Ex.物販システムの場合、仕入・販売・配送など
- プログラムを適用する対象となるビジネス/業務領域

## ドメインモデル
Ex.金銭、帳票、商品など
- 実際の業務で重要な要素を連ねる
- 大事なのは業務に必要な情報だけ洗い出す
- ドメインの概念をモデリングして得たモデル

## ドメインオブジェクト
- ドメインモデルをモジュール化したコード
- 業務プロセスが変わりドメインが変わっても対応するモジュールを改修すればいい

### 値オブジェクト（システム固有の値をクラス化）
Ex: 姓名からなる氏名
- ドメイン固有の概念を値として表現するクラス
- 値だけでなく値のルールや振る舞いも持たせる
- 同一性ではなく属性によって識別される
- 同じ属性なら同じオブジェクトとして判断
#### メリット
- 不正値の代入をコンパイル時点で発見できる
- どんな値なのか読み解くのが楽

### エンティティ
Ex: 氏名が同じでも同じ人とは限らない、ユーザ名を更新しても同じユーザ
- ライフサイクルを持つドメインオブジェクト
- 同一性によって識別される
- 同じ属性でも同じオブジェクトとは限らない
- 属性が変わっても同じオブジェクト

### 値オブジェクトとエンティティの共通
- ドメインモデルを実装したドメインオブジェクト
#### メリット
- 値に対するロジックがコード内で散乱しない
- ドメインにおける変更を適用しやすい

## サービス
- クライアントのために何かするオブジェクト

### ドメインサービス
- ドメインのためのサービス（振る舞い）
- ドメインオブジェクトに定義しては不自然な振る舞いを定義
- 複数のドメインオブジェクトを使用する操作など

## リポジトリ
- データを永続化（保存）して再構築（復元）する処理を抽象化するオブジェクト
- データはデータストアで管理される
- リポジトリが直接データストアを処理
- 特定の属性を更新させるような振る舞いは定義しない
- 関数が大量になるので引数にオブジェクト自身を渡して丸っと更新する

## [境界づけられたコンテキスト](https://little-hands.hatenablog.com/entry/2017/11/28/bouded-context-concept)
- システム全体のモデルを統合するのは実現不可能なので、分割してコンテキスト内でモデル/言語の統一を目指す
- ドメインを分割してユビキタスが通用する範囲を明確化して、区切ったコンテキスト内にモデルを配置していく
- レイヤや技術単位ではなくドメインの分割によってソースも分割する

### ユビキタス言語
Ex:

|名称|意味||
|---|---|---|
|ユーザ|システム利用者||
|配送|||
|商品|||
|商品|||

- ソフトウェア開発者やドメインエキスパートが共通で使用する言語
- 誰と話すときもプログラム書くときもドキュメント作るときも統一した言語を使う

## アプリケーションサービス

- システムが実現するユースケースの振る舞いを定義
-