どのレイヤー（層）でトランザクションを実装すべきか

このように、層ごとに関心事の分離を行うことで、保守性の高い（変更容易性や再利用性等）アプリケーションを実現できます。 しかし、「トランザクション」においてはどうでしょうか。 トランザクションはビジネス領域においても、技術領域においても関心事がある内容です。 そういう曖昧なものは「ひとまず usecase 層に入れてしまえ」という方針になりがちです。 ですが、DB 固有の知識を usecase 層の関心事にしてしまっては、関心事の分離をするメリットが得られません。 そのため、関心事の分離を実現しつつトランザクション実装をする方法を模索してみました。 前提 1. クリーンアーキテクチャを採用している（オニオンアーキテクチャやレイヤードアーキテクチャも含む） そもそもビジネス知識と技術知識を分離していないアーキテクチャを採用している場合、メリットは得られません。 そのため、オニオンアーキテクチャ

[NetPenguin]

これ系の話、DBのトランザクションの事なのか、それとも一連の業務処理のことを指しているのか、最初に明示されていてほしい（途中でビジネストランザクションって記述があったので、主題はDBのということはわかる）

[nil0303]

トランザクション境界をドメイン層に置くかインフラ層に置くか問題。業務的に複数のドメインオブジェクトの更新が必要なケースにモメる。整合性の厳密さを前提にしつつ派閥が別れていると認識している。

[xlc]

「レイヤー」は独自定義なのでよく分からぬが、トランザクション分離レベルがこの規定では性能が出ないのでは。書き込みが多いと読み出し側でロックがかかりっぱなしになる。ロックは通常更新時のみにすると思う。

[onesplat]

id:xlcがトランザクションやロックをどの程度理解してるのか不安

[prograti]

主題から逸れますがUnit of Workの解釈にちょっと違和感がありますね

[strawberryhunter]

DDDって百家争鳴よね。私はどこに書いたら都合が良いかで決めるべきだと思っているけど、DDDはこうあるべきみたいな要素も入ってくるから難儀な宗教かもしれない。

[nakag0711]

usecase層で実装してinfra層で実装しないなんてことが可能なの？

[ch1248]

いいですね

[tattyu]

いつも思うんだけど、入力と出力を同じレイヤーで扱うのやめた方が良いのでは。