Springの３層モデルでのServiceの使い方について

Question

現在、SpringBootでAPIを作っており、３層モデル(Application, Domain, Infrastructure)で設計しています。

その中で参考にしたアーキテクチャ図が以下のNTTDataのTERASOLUNAのものです。
![

ここで質問したいのが、Contoroller側で複数のServiceを呼びたい時の呼び方についてです。

Controller側は１つのServiceを呼び、そこから他のServiceを呼ぶのか、
Controller側で必要な複数のServiceを呼ぶのか。
どちらが良いのかわかりませんでした。

例えば、複数のServiceを使用する場合に、AService、BServiceがあったとして、
AServiceの処理結果をBServiceで用いる場合は、
前者の場合は、ASeviceの処理の中で、BServiceを呼び、その２つの処理の結果を呼び出し元に返す。
後者の場合は、ASeviceの処理結果を呼び出し元に返し、その結果をBServiceに渡して、BServiceの結果を受け取り、この２つの処理の結果を呼び出し元で結合する。
となるイメージです。

私的には、前者の方がしっくりきます。なぜかというとContoroller側ではなるべくロジックをもたせたくないからです。
後者の場合、結果の抽出や結合のロジックがApplication層に入るので、設計的にどうなんだろうとふわっとした疑問があります。

それともにその結合や抽出などのデータ処理を、このアーキテクチャ図でいうHelper逃して、
後者で実装するべきなのでしょうか？

ご意見を伺いたいです。

Answer 1

Controller側は１つのServiceを呼び、そこから他のServiceを呼ぶのか、

Controller側で必要な複数のServiceを呼ぶのか。
どちらが良いのかわかりませんでした。

こちらについて制限はありません。
（アプリケーションを設計・実装する際の規約になることはあります。）
なお、実際にServiceクラスから別のServiceクラスを呼び出すことはあり得ます。ServiceクラスはWebアプリケーションから呼び出されることだけを想定したクラスにしないことが指針です。

https://docs.spring.io/spring/docs/current/javadoc-api/org/springframework/stereotype/Service.html

1Controllerから常に1つのServiceしか呼び出さない（呼び出せない）作りはControllerの実装が簡潔になりますが、Controllerから呼び出されるServiceクラスの責務が重くなります。わかりやすい事例では、Serviceから別のクラスを呼び出す関係性や制御を担うことになり、メソッドや引数のパターンが増える懸念があります。ただしトランザクション境界をController-Service間へ画一的に設計できる楽な面があるでしょう。

1Controllerから複数のServiceを呼び出す場合はServiceクラスの責務は軽くなり、Serviceクラスを呼び出す順序はControllerによって制御されます。一見こちらが良さそうに思えますが、トランザクション境界を@Controllerに置くか、特定の@Serviceに置くかを検討しなければならないでしょう。

WebアプリケーションないしはWebAPIとして提供する場合、ServiceクラスはWebのレスポンス内容に依存した結果を返さない想定であるため、Terasolunaの実装例ではHelperが用意されています。
これをViewModelなどの出力用クラスに置き換える設計指針もあります。（個人的には、Helperという名前がやや曖昧にも感じます。）

Answer 2

Controller側は１つのServiceを呼び、そこから他のServiceを呼ぶのか、

Controller側で必要な複数のServiceを呼ぶのか。
どちらが良いのかわかりませんでした。

ここは要件次第だと思います。
コントローラにどこまでの役割を持たせるのか、
サービスにどこまでの役割を持たせるのか。

画面や機能によっても違うと思います。

サービスとコントローラがどれくらい密接になっているかにもよると思います。
もし他のサービスで同じような機能が呼び出されているのでしたらなるべくそちらを使ったほうが良いでしょうし、ないのでしたらそのコントローラ独自の機能ということで自分のサービスに書くしかないと思います。

ただ、サービスからサービスを呼ぶというのはあまりないと思いますので、
「コントローラから必要なサービスを呼ぶ」が正解とは思います。

私が以前関わった業務ではJUnitによる単体テストはサービスのみを通していました。コントローラはあくまで「サービスを通して画面に必要な情報を取得する場所」という位置づけであるためですね。

つまり、

後者の場合は、ASeviceの処理結果を呼び出し元に返し、その結果をBServiceに渡して、BServiceの結果を受け取り、この２つの処理の結果を呼び出し元で結合する。

この場合、「A」だけ「B」だけで単体評価が可能となるのか？というのがカギになってきます。
もちろん、「Aを呼び出した結果を利用してBのテストを通す」という前提にすれば可能かもしれませんが、
それだと単体というより結合なので、やはりあくまで単体で要件が完了することが望ましいと思います。

コントローラに返ってくるのはBの結果なので「Aって何のためにあるの？」という疑問もあります。
こういったモデルも本質的には役割分担を目的としているので、なるべく「部品を作って組み立てる（組み合わせる）」ような考え方ができれば良いのではと。
「Aが単体で使われるのか」「Bが単体で使われるのか」という部分も含めて設計ですね。