データクラスと機能クラスを分けることで起きる弊害
どこにでも機能を書けてしまうため、凝集度が下がる
問題の特定時に調べないといけない範囲が広い
1つのことを変更するために、修正すべき範囲が広い
修正によるデグレが起きていないことを確認するためのテストが大量に必要
DDD:アプリケーション層の構造が、画面の構造に引っ張られる
アプリケーション層の機能クラスと、Viewが密結合する
複数の機能クラスに、同じドメインロジックが重複する
View駆動良くない
DDD:アプリケーション層の構造が、DBの都合に引っ張られる
機能クラスを、tableのCRUD操作単位にしてしまう
機能クラスと、tableが密結合するということか #??
そうじゃないパターンはどんなパターン #??
Utilityクラスのようなものを用意しても上手く行かない
汎用的にするが、個々で微妙に要件が異なる場合に対応できない
対応すると、flugの引数を取ったりしてしまう
逆に、具体的なmethodを作るとmethod数がめちゃくちゃ増えるので探すのが大変
これも結構渋い問題なんだよな
物が多すぎると探せない
初見のときに、そこを一望していても、今後誰かに似たようなものを追加されているかも知れない
毎回確認するのも大変なので結局、独自のものを各々が作るようになってしまう
こうやって見ると、そもそもSymfony使っている時点で、やっぱり良い設計を実践するのって無理だな、と思うんだけどどうだろう
フレームワークが、データクラスと機能クラスの分離を半ば強制してくる
工夫すればどうにかなるものなのか？
どうやって解決するのか？
要は、データと機能を同じ場所に書く
参考