ドメインモデル貧血症はなぜ生まれるのか — Decision パターンで DDD トリレンマを解く

テラーノベルで Go を書いている typer です。 この記事は次のような方向けです。 Go でコードを書いていて、domain 層にロジックが集まらないと感じている方 DDD の戦術的パターンを入れてみたが、結局 domain の外側にロジックが溜まっている方 リポジトリを呼ぶために domain に context と error を持ち込むかどうかで迷ったことがある方 先に結論を書いておきます。 ドメインモデル貧血症は、怠慢ではなく構造的なトリレンマの結果として生まれやすい 「判断するために何が要るか」を型で返せば、型の制約を保ちながらトリレンマは解ける 「戦術的 DDD は意味がない」という評価 先日 X で、DDD とクリーンアーキテクチャの評価についての投稿が流れてきました。戦術的パターンについて次のように書かれています。 戦術的パターン(Entity / Value Obj

[Magicant]

発想の筋は良さうだけど Go を読み慣れてないのであまりすんなり頭に入って来ない

[nguyen-oi]

DDDトリレンマを直和型っぽく解くのは綺麗だけどGoだと記述量が増えて辛そう