Action-Service-Logic の3階層は冗長か？

エンティティ固有のドメインロジックは別出しにします。
ひがさんが最近呼んでる「Service」に近いです。
でも、みなさん Action-Service-Logic の3階層は冗長ってお考えなんですね。

そうでもないですよ。今、私が携わらせて頂いている案件では、

　Action ：　コントローラ
　Service：　ユースケース単位のロジック + データアクセス
　Logic　：　エンティティ単位のロジック + データアクセス 

　※ LogicはActionとServiceの両方から呼び出し可能とする。

の方式に数人の中核のメンバーから納得感を得ています。
無難な選択肢だと思います。

一見冗長に思えますが、「ユースケース単位のロジック」と「エンティティ単位のロジック」を１種類のクラスに寄せる方式はどこかで無理が生じてしまいます。そう考えると、この方式は自然な発想ではないでしょうか。

この方式のポイントは、LogicをActionからも呼出し可にするかどうかです。階層的なアーキテクチャを重視すると、呼び出し順が Action → Service → Logic となり、設計的には美しい感じがします。しかし、Actionから直接「エンティティ単位のロジック + データアクセス」を呼び出したくなるケースでも、わざわざLogicをService経由で呼び出さなければならないので冗長になってしまいます。そうならないためには、階層を取っ払ってLogicはServiceとActionの両方から呼び出し可能にする方が良いと思います。そう考えると、この方式はAction-Service-Logicの3階層とAction-Logicの2階層、Action-Serviceの2階層が共存するアーキテクチャとなります。階層を飛び越した呼出しを許さない常に3階層のアーキテクチャと区別するために、以下ではこのアーキテクチャを２〜３階層の中間をとって『2.5階層のAction-Service-Logicパターン』と呼ぶことにします。

現在、この『2.5階層のAction-Service-Logicパターン』と『1.5階層のAction-Serviceパターン』のどちらが良いかを思案中です。1.5階層のAction-Serviceパターンの基本構成は次のとおりです。

　Action ：　コントローラ + ユースケース単位のロジック + データアクセス
　Service：　エンティティ単位のロジック + データアクセス

1.5階層のAction-Serviceパターンの詳細については、別のエントリで紹介します。