サーバーサイドの実装でドメインモデル貧血ぎみなのもそうだけど、そもそもドメインモデルのあるべき状態がわからなくなっていた
そのとき次の記事で、あるべき姿と、あるべき姿にトレードオフがあるということがわかった
ドメインモデルのあるべき姿に完全性、純粋性があげられるが、これらトレードオフがあり両立が難しい場合があるよねという話
例えば
「変更しようとしているメードアドレスが他のどのユーザとも重複してないこと」
をどこで実装するか（詳細は記事参照）
これはユーザーがもつメールアドレスなので、ユーザーに閉じ込めるようにしたいが、1ユーザの集約の範囲を超えるのでデーターベース精査が必要になる
このとき以下のようなトレードオフが発生する
- 完全性のためにUser内でやるようにしたら、別のレイヤーに依存するため純粋性が失われる
- 純粋性のためにアプリケーションレイヤー内でやるようにしたら、完全性が失われる
そのため、どちらか一方を選択しなければならない
記事だと、純粋性を守る方が多いとのことだが、アプリケーションレイヤーでのビジネスルールのチェック漏れの懸念があるので工夫が必要とあると書かれている
例えば、GoFのMementoパターンを使ってビジネスルールのチェック済みの型を設ける方法で回避する実装が紹介されている
たしかにこれで、純粋性を守りつつ、チェック漏れを防ぐことができそう
感覚的に私も純粋性を守った方がシンプルかなと思うので、このやり方を検討してみる
