クリーン/レイヤードアーキテクチャ
層に分け依存方向を整理することで、ビジネスロジックをフレームワーク・DB・UIから独立させる設計。_moc-web-infra
基本原則
「関心の分離」と「依存性の整理」に帰着する。view にビジネスロジックを書かない。ユースケースは Interactor として実装し、コードのエントリポイントからロジックを分離する。クリーンアーキは厳密には「オニオン+SOLID」と捉えると分かりやすい。
層と責務
- Controller/Presentation: validation、モデル⇔DTO変換。
- Service: ビジネスロジック。トランザクション境界をここに設ける。
- Repository: 永続化操作の抽象。実装は infra 層(
RepositoryImpl)に置き、domain は infra に依存しない。 - domain に infra(tx, 一貫性チェック)が混入するのを100%は防げない。責務分離が目的。
サービス間呼び出しの是非
- ユースケースは基本再利用しない。Service から別 Service を呼ぶのは原則禁止。
- 共通化したい処理は
SharedServiceに切り出す(トランザクション境界にならないことが多い)。 - ユースケースが肥大化したらアクターを小さく分ける(支払い部分だけ
Payerにする等)。そもそも巨大なユースケースは設計が間違っている可能性。
トランザクションの横断
N層アーキテクチャでトランザクションをクリーンに扱う解の一つが Unit of Work パターン。複数のRepository操作を1つの作業単位としてコミット/ロールバックする。DI とインターフェースで実現する。
設計判断
技術者は特定技術に熱中しやすいので、トレードオフ分析(分析的視点で良し悪しを判断)が重要。弾力的スケーリング(ユーザー数に応じたスケール)など非機能要件も設計に含める。