前置き
エピックサーガの状態をクリーンアーキテクチャの同心円で表現すると、複数のビジネスドメインのロジックが、単一の巨大なユースケース層（あるいはサービスクラス）の内部で密結合している状態と見なせます。
エピックサーガにおける結合点
エピックサーガの段階では、複数のドメイン（在庫、決済、顧客など）のデータが、単一のデータベースインスタンス内に存在します。
これにより、アトミック整合が成立し、極めて強力な一貫性保証が手に入ります。
CAP定理のCに完全に偏っている状態。
ただし、クリーンアーキテクチャの理想は、各ユースケースが単一の責務を持つことです。
それを踏まえると、エピックサーガの段階では、以下のような問題が発生しています。
巨大なユースケース
一つのOrderServiceクラスのplaceOrderメソッドの中に、「在庫確認」「決済処理」
「顧客ランク更新」「クーポン適用」「配送情報登録」といった、本来なら異なるビジネスドメインに属するべきロジックが、手続き的に（上から下へ）記述されています。
ドメイン知識の混在
この巨大なユースケースは、注文ドメイン、決済ドメイン、在庫ドメイン、顧客ドメインの知識をすべて知っている状態です。
これは、複数のドメインのエンティティやビジネスルールが、単一のユースケース層で直接的に結合していることを意味します。
直接的なDB操作
各ドメインのロジックが、それぞれのデータベーステーブルを直接、同じトランザクション内で更新していきます。
これにより、ユースケース層が複数のデータ構造とも密結合になります。
逆にこの蜜結合があるからこそ、
エピックサーガの頃は、複雑な分散トランザクションは不要になり、
データベースがネイティブに提供するACIDトランザクションの仕組みによって、
ロールバックも極めてシンプルに、かつ自動的に行われます。
シンプルさの代償
このトランザクション管理のシンプルさは非常に魅力的ですが、大きな代償を伴います。
開発のボトルネック
全てのチームが単一の巨大なデータベーススキーマを触るため、変更が衝突し、当然コミュニケーション調整コストが増大し、開発速度が低下する。
スケーラビリティの限界
データベースが単一障害点となり、システム全体の性能のボトルネックになる。
技術的な制約
各ドメインに最適なデータベース（NoSQLなど）を選択することができない。
マイクロサービスへの移行は、
このシンプルで強力なトランザクション保証をあえて手放し、
サーガパターンや補償トランザクションといった複雑な仕組みをアプリケーション層で再実装することで、スケーラビリティや開発の自律性を得る
という、アーキテクチャ上の根本的なトレードオフなのです。
だからこそ、何か月～時には数年単位で道中の移行フェーズ中での痛みや運用の複雑さと向き合うだけのお金と体力が必要です。
結論
エピックサーガは、まさに 「クリーンではない」 アーキテクチャの典型例です。
単一のユースケース（または少数の巨大なユースケース群）が、複数のドメインロジックを抱え込み、結果として
ユースケース層がシステム全体の結合点
となってしまっているのです。
これを解決する第一歩が、イベントストーミングなどを使ってユースケース層に混在したドメインを見つけ出し、それぞれを独立したユースケースへと分割していく（＝サービス境界を発見する）作業になります。
ココを起点として、次のおとぎ話サーガへ移行を次の記事で追っていきましょう。