ユースケースが見つけづらい問題
from 従来のレイヤードアーキテクチャの問題点
アーキテクチャ で重要なのは、機能の追加や変更をする箇所が コードベース のどこなのか簡単に把握できるような構造であること
開発者がどこに実装するのかを見つけるのに費やす無駄な時間を減らすため
従来の レイヤードアーキテクチャ はこれをあまり得意としない
理由
1. ビジネスロジック が様々な層に散在する傾向にある
テストが書きづらい問題#66bc985e75d04f0000544f7c
2. サービスが扱える ユースケース の数にルールを設けていない
時間が経つに連れて、複数のユースケースを扱う単一の肥大化した サービス になる
https://scrapbox.io/files/66bc9c84099f0d001dbf305e.png
このようなサービスは Web 層の様々なコンポーネントから依存するため、テストがしづらくなる
+ 目的のユースケースがどこで扱われているのかを見つけるのが難しくなる
e.g. ユーザを登録するユースケースを探す場合
🙆 RegisterUserService という責務に特化したサービス
簡単にユースケースを見つけ出せる
🙅 UserService というユーザに関するユースケースをすべて扱うサービス
対象のユースケースを見つけるのに、UserService のクラスを見て、該当コードを探す手間と時間がかかる