これは、そのエンティティの処理を１つにまとめられて見通しのよい方法だと思う。
でも、アプリケーションの規模がだんだん大きくなると、ちょっと問題が見えてくる。
同じエンティティの処理でも、ジョインする必要のあるエンティティが違ってきたりなどと、
微妙に処理が違うことが出てくる。
上記の場合は、あらかじめ関連エンティティを全てジョインしておくか、
メソッドを分けるかで対応ができるかもしれないが、どちらもあまり好ましくない。
１本化するために、不要なものまでジョインするのは、リソースの無駄な気もするし、
メソッド分割は、ちょっとだけ違う処理のメソッドが乱立して収集がつかなくなりそう。
そんなことを思ってた時に、ある書籍のCOLUMNでこの問題が取り上げられていた。
その内容では、共通化はある程度諦めて、機能単位や、ユースケース単位でサービスを作る方が
部分部分での見通しは良くなると言っている。
なるほど。サービスを物理的に分けるのか。クラスが増えるが、著者の経験上そっちのが良かったのだろう。
スーパークラスと、リストテーブルのようなジョインされるだけのものは共通化にして、
あとは、アクション毎にパッケージ分割してるのを想像すると、今後のためには良い気がしてきた。
システムの仕組みの根本の部分だから、やるなら早めがいいよなぁ。取り組んでみるか。
