その中で、私にめちゃくちゃ刺さったことについて書き残しておこうと思います。『現場で役立つシステム設計の原則』では、第5章の話に相当します。それプラス、読書会で出た話や、私個人の感想が含まれます。要約サービスは単機能で作る複数のサービスをひとつのまとまりとして扱いたいときは、単機能のサービスを複数まとめた新しいサービスを作るこれがいわゆるユースケースとなっていく階層は必要になった時に作ればいい階層ありきで設計すると、無駄なクラスをつくるハメになる感想ずっと悩んでいたわけですよ。どの階層に何を置けばいいのか、どのように階層を作ればいいのか、ということに。言っている今でも、サービスって何さ?ユースケースって何さ?モデルって何さ?ってよくわからなくて試行錯誤して階層を分けたり分けなかったりしているのです。してもどこかにただデータを横流ししているだけのようなクラスを含む階層ができたり、逆に色んな要素がつめ込まれてしまうクラスができたりしまいます。してもどこかに歪が出てしまう。それは確かに、より自然であるように思えます。最初から○○層!って気合を入れる必要なんてなかったのです。階層ありきで作るから、○○層って何書けばいいの?とか、書いては見たけれど本当に必要なのかどうかわからないようなクラスができてしまっていたのです。そんなわけで、これからは必要なものを必要な分だけ書いていこう、と思ったのでした。「モデル」に対しては完全に振りきっていて多くの別々の人達にとって、その意味合いは様々なため、"models"という言葉の定義は曖昧であることに私達は気づきました。ある開発者たちはすべてのビジネスロジックを総称してアプリケーションの「モデル」と呼び、一方で別の人達はリレーショナルデータベースに関連するクラスを「モデル」として参照しています。Laravelとかいいだす始末です。想起*1してしまって「えええええ?」となってしまったのでした。一度読むと全然そんなことは言っていないことがわかったのですが・・・。