6/13
質問はquerie.meからお願いします。
#peingddd 面白いトピックですね！今回のご質問の内容なら、集約を分けるのが良いと思います。(続)
Other answers
Sponsor link
Sponsor link
Sign In with Twitter
You must agree
Terms & Services
and
Privacy Policy
.
Sponsor link
![質問をさせて下さい。
ユーザーと企業でやり取りができるメッセージングシステムがあるとします。
一度メッセージを送ると、スレッドができ、スレッドの中にメッセージが溜まっていく
アプリケーションの動作となります。
[ユーザー]、[企業]、[スレッドとメッセージ]という3つの集約で作成しています。
スレッド集約は、スレッドをルートエンティティとし、メッセージのコレクション（Javaで言うList？）
を持つようなイメージです。
こちらの構造を前提として、インフラ層の実装について質問をさせて下さい。
レポジトリーでは、集約ごとのトランザクションになりますので、スレッドを軸での更新になると思いますが、
1つのスレッドに1000件のメッセージが含まれていた場合、1000件のアップデート文を発行する形になるかと思います。
※ 書き方の問題ではなく、1000件のデータを更新しなければならないという問題を伝えたいです。
さらに、レポジトリーから見て、データにどのような変化があったのかわからないため、
1000件を更新せざるを得ない状況だと思います。
・ユーザーが1つのメッセージを追加しただけかもしれない
・100件分のメッセージが既読になったかもしれない
そこで、メッセージエンティティにrecentlyCreatedやhasChangesなどのメソッドを追加し、
レポジトリー側でそれを見ながら更新する方法が思いついたのですが、
レポジトリー層のためだけの仕組みをドメイン層で実装するような方法になってしまうため、
スマートな解決方法に見えません。
ドメイン駆動設計を使う以上は、整合性を保つためにインフラの負担を妥協しないといけないということも
承知していますが、想像もつかない数のアップデート処理を許容できない自分も居ます。
この例では、1000件のメッセージですが、1万かもしれないし、1000万かもしれないという問題が気になります。
設計そのものの問題やスマートな解決方法がございましたら、是非アドバイスを頂けないでしょうか？
恐縮ですが、ご検討下さいませ。](https://s3.peing.net/t/uploads/eyecatch_image/file/3f3ef719ce673f156e2e3bbb8720038c8db9fa2b7dfea79fc112606c07486f79f6dc4af1af65442b23faa922dc6b1677c43a6144ecfeffedc5e7c3ec5f942624.jpg)
