なぜ共通ユースケースで委譲を使うのか
誤解が無いように注意がいる箇所として、重複部分の全ては継承と述べているのではないです。次のように、委譲モデルも併用しています。
複数のユースケースで使われるロジックは、共通のユースケースを抽出し、共通のユースケース名Serviceクラスに持たせる。
なんとなく、このような設計にした方が良いとは思いますが、なぜ、上記のような局面において、継承モデルではなく、委譲モデルを採用したのか理由が気になるところです。
私は、単にシンプルさを求めるだけではなく、複数の人で並行で開発しやすいということも常に重視しています。一つのユースケースは一人で開発することが多い(もしくは効率が良い)と思っているので、同一ユースケース内の複数ページで共通に用いられるロジックは、同一ユースケース内の共通親クラスにもたせることで、シンプルかつ更新がぶつからずに開発できると思っています。
しかし、複数のユースケースで共通的に用いられるロジックを、すべてのユースケース用の共通親クラスに持たせると、その共通親クラスの更新がいろんなところでぶつかることが予想されます。別のクラスに切り出しているのは、更新がぶつからないようにするためです。
また、共通のユースケースを実装している人は、共通ロジックチームみたいな部隊が担当して、個別のユースケースを実装しているチームとは、異なることが多いだろうという読みもあります。
一つのユースケースは、一人(もしくは少数のチーム)で最初から最後まで開発する「セル型生産」が、コミュニケーションロスもなくなるし、最も効率がよいと思っています。
