hrgnnk

[hrgnnk @Vo4VeareR9EB]

@alkaidy2025 If consistency across multiple aggregates is required, it is necessary to guarantee consistency at the application level using techniques such as the saga pattern.

[hrgnnk @Vo4VeareR9EB]

この手の勘違いをしてる人は大体次の二点を履き違えてる

一つ目はRepositoryはRDBに保存するという先入観。書き込まれたデータはRDBに保存しなくても、それこそ昔の2ちゃんねるみたいに直接ファイルに書き込んだっていい。それを抽象化するために用いるのがDomainRepository

[もりた / SoftwareDesign連載中 @mconfjp]

ここでも「Repositoryの裏にDBを隠すと、トランザクション設計やクエリ最適化といったDBの強みを捨てがちになる。」って書いてる
まあこれはFableが間違ってるだけだと思うけど...
トランザクション設計はリポジトリでやるべきじゃないしクエリ最適化は機能要件に影響をあたえずにリポジトリ内で改善できるからむしろやりやすかったりしないのだろうか。。

[hrgnnk @Vo4VeareR9EB]

@alkaidy2025 This is because, in Domain-Driven Design, an aggregate equals a transaction boundary; the repository is not merely an object in the data access layer, but rather an object that persists data in units called aggregates and ensures application consistency through transactions.

[hrgnnk @Vo4VeareR9EB]

@mconfjp そうなりがちなのかなと考えています

[hrgnnk @Vo4VeareR9EB]

@mconfjp ですが本来リポジトリ内部にDBの詳細は隠蔽されるからこそ、例えば単一のドメインエンティティであってもDBの設計的には複数テーブルに分割されていてもよいはずです

しかし大体そうならないのは、既存のフレームワークのORMに慣れ親しんだ開発者が慣れない設計手法になんとか取り組んだ結果、

[hrgnnk @Vo4VeareR9EB]

@mconfjp でも前に挙げた二点を誤解しているとトランザクション設計が複雑になった結果、その設計を捨てたり、クエリ最適化を諦めるみたいなことに陥りがちだよね〜ということです

[hrgnnk @Vo4VeareR9EB]

@mconfjp なので複数ドメインエンティティに跨るような読み取り・書き込みであってもそのリポジトリ境界内の責任において任意の最適化やトランザクション設計が本来可能なはずです