Toy と帽子と ADP BE

主にプログラミングに関わる話をゆるくエモくやっていきます

サービスと階層の話

【大阪】9/16 現場で役立つシステム設計の原則 読書会【第5回 in 豊中】 - connpass に行ってきました。その中で、私にめちゃくちゃ刺さったことについて書き残しておこうと思います。

なお、『現場で役立つシステム設計の原則』では、第5章の話に相当します。それプラス、読書会で出た話や、私個人の感想が含まれます。

要約

  • サービスは単機能で作る
  • 複数のサービスをひとつのまとまりとして扱いたいときは、単機能のサービスを複数まとめた新しいサービスを作る
  • 階層は必要になった時に作ればいい
    • 階層ありきで設計すると、無駄なクラスをつくるハメになる

感想

ずっと悩んでいたわけですよ。どの階層に何を置けばいいのか、どのように階層を作ればいいのか、ということに。

古くはいわゆる MVC やその亜種に悩まされてきましたし、やれ DDD だやれ Clean Architecture だと言っている今でも、サービスって何さ?ユースケースって何さ?モデルって何さ?ってよくわからなくて試行錯誤して階層を分けたり分けなかったりしているのです。しかし、どうしてもどこかにただデータを横流ししているだけのようなクラスを含む階層ができたり、逆に色んな要素がつめ込まれてしまうクラスができたりしまいます。どうしてもどこかに歪が出てしまう。

でも、無理に階層を分けないで、小さい単位で組み立てていって、ある程度まとまった固まりに対して必要となった時に初めて階層を用意するとしたら? それは確かに、より自然であるように思えます。

最初から○○層!って気合を入れる必要なんてなかったのです。階層ありきで作るから、○○層って何書けばいいの?とか、書いては見たけれど本当に必要なのかどうかわからないようなクラスができてしまっていたのです。

そんなわけで、これからは必要なものを必要な分だけ書いていこう、と思ったのでした。

余談

PHP の有力なフレームワークである Laravel ですら「モデル」に対しては完全に振りきっていて

多くの別々の人達にとって、その意味合いは様々なため、"models"という言葉の定義は曖昧であることに私達は気づきました。ある開発者たちはすべてのビジネスロジックを総称してアプリケーションの「モデル」と呼び、一方で別の人達はリレーショナルデータベースに関連するクラスを「モデル」として参照しています。 ディレクトリ構造 5.5 Laravel

とかいいだす始末です。(まあ実際そのとおりなんですが)

余談その二

『現場で役立つシステム設計の原則』の第3章を初めて読んだ時、なぜか今回の話に出てくる(古き悪しき)MVC を想起*1してしまって「えええええ?」となってしまったのでした。もう一度読むと全然そんなことは言っていないことがわかったのですが・・・。あの感覚はなんだったのだろうか?

*1:フラッシュバックと表現したほうが適切かも