Repositoryの実装ではRepositoryの実装方法と分割の方法を見てきました。
Repositoryの分割はドメインモデルと密に関わっているのですが、その部分を省いて説明していたため、ここではドメインモデルに焦点を当てて説明をしていきます。
Repositoryの実装ではライフサイクル単位、役割単位、状態単位で分割する例を見ましたが、DDDでは集約の単位で分割するように言われています。
集約はほとんどの場合ライフサイクル単位で分割されます。
Repositoryを分割するということはドメインモデルを集約単位で分割するということであり、ひとつの集約が複数のRepositoryを使うことはありません。
つまり、Repositoryを分割したら集約も分割され、それによって専用のエンティティが作られることになります。
ここで言いたいのは、Repositoryを優れた単位で分割するにはドメインモデルを進化させる必要がある、ということです。
Repositoryの実装で説明した実装方法を用いれば、たとえRepositoryを分割する単位が変わったとしてもテーブル構造を変更する必要はありません。valueテーブルを参照するRepositoryが変わるだけです。
Repositoryを簡単に変更できるため、ドメインモデルの進化のスピードとデータモデルの進化のスピードのズレが少なくなり、インピーダンスミスマッチを抑えることができます。
テーブル定義をするときに過度な制約(主にcheck制約)をしていることがありますが、これにはいくつかの問題があります。
簡単な例を挙げると、文字数制限がこれに当たります。
値オブジェクトで文字数制限をしているにも関わらず、テーブル定義でも同じ制約を定義しています。
更に問題なのが、値オブジェクトで指定している文字数とテーブル定義で指定している文字数が異なることがある、ということです。
値オブジェクトの文字数制限をある程度柔軟に変更できるようにするため、テーブル定義では広めの文字数制限をすることがよくあります。
これはユースケースとは異なる制約をデータモデルに課していることになり、意図が伝わりづらくなっています。