概要
ドメイン駆動設計入門を読んだのでメモ。
間違いがあるかもしれないので、正しい情報は書籍で確認してください。
重要なポイント
ドメイン駆動設計は、解決したい課題の領域について知識を得ながら設計を行う設計手法。
オブジェクト指向プログラミングが重要な要素の１つになっており、本書では設計パターンを中心に解説している。
パターンと対をなすモデリングは本書では、ほとんど扱っていない。あくまでドメイン駆動設計の開発を学ぶのに必要となる知識を学ぶ。
設計パターン
下記のパターンが紹介される。思い出せなくなったら、本書を読み返すと良い。
文字列型などのプリミティブ型を使うのではなく、ドメイン特有の値を表すクラス＝値オブジェクトを使用する。例えばお金を表す場合に、int型を使うのではなくmoneyクラスを用意する。
値オブジェクトは比較可能である必要がある。moneyクラスでいうと、金額と通貨が同じ場合に同一であると判定する。
また、不変かつ交換可能である必要がある。moneyクラスを一度インスタンス化したら、インスタンスの属性を変更することはできない（不変性）。
値を変更したい場合には、別の値をもつインスタンスを作成し、既存のインスタンスと交換する必要がある。
一方、エンティティは可変かつ同じ属性であっても区別される。userクラスを考えると、エンティティがわかりやすい。ユーザ名は変更する。そして、同じユーザ名であっても必ずしも同一のユーザであるとは限らない。エンティティはそのような性質を持つ。エンティティの判断基準（値オブジェクトとの違い）は、ライフサイクルをもつかという点である。ユーザのように作成され、いずれ削除されるような概念はエンティティと判断される。
値オブジェクトやエンティティをドメインオブジェクトと呼ぶ。ドメインオブジェクトには文字数や文字種チェックなどのふるまいが定義される。値やエンティティ自身の性質や制限を、ドメインオブジェクトのクラス内に記述する。
一方、ドメインオブジェクト間の制約はドメインサービス（クラス）に記述する。例えば、同じユーザ名の重複を許可しない場合は、UserServiceクラスを作成し、ドメインサービスで重複チェックを行う。
リポジトリは、データストアとの連携に使用する。ビジネスロジック（UserApplicationService、アプリケーションサービス）内に、データストアへのアクセスを直接記述すると、処理内容の把握が難しくなる。そこでリポジトリのインターフェース（IUserRepository）を作成し、具体的なクラス（UserRepository）に処理を記述する。ビジネスロジックのプログラムでは、インターフェースに対して操作を行う。これは依存関係逆転の原則に従っている。UserApplicationServiceはIUserRepositoryに依存し、UserRepositoryはIUserRepositoryに依存している。
