Ruby on Rails、Hanami 、アーキテクチャ

最近規模の大きなアプリケーションの設計について考えている

どれくらいかというと具体的にはまだわからないが、もうこの時点でRailsでおとなしく考えたら破綻するのが見えてるくらいものである

そこで考えたことや見えてきたこと、ただの事実などポエムを書いていこうと思う

ひとまずRailsについて

Railsはリソース1つにコントローラ1つにモデル1つと全て1:1で結びついてる

そもそも別の処理が同じコントローラ内に書かれるし、コールバックなどに条件分岐が起きる。これはSRPやオープンクローズドの原則に反している

しかしRailsとしてはこの辺りはアプリケーションの規模や開発速度とのバランスを考えた結果こういうアーキテクチャ、ルールを選択している

もうひとつHanamiがある

これは、クリーンアーキテクチャ、DDDを参考としたアーキテクチャを選択している

僕は設計としてはHanamiのほうが正しく、イケてると感じる

しかしHanamiは一向に採用されず、全く流行っていない

様々な要因があるかとは思うが

  • 最初は初速の出るRailsを採用しがち

これがやはり大きな要因になってるはずである。アプリケーションは最初はそこまで複雑ではなく、少しづつ成長し、大きくなっていく

 

ここで初速、開発効率とは一体なんなのかともう一度考えてみる

さっきはアーキテクチャとしてバランスを見ていると言ったが、おそらくこれはそこまで大きく関係しない

確かにHanamiにするとファイル数、記述数は増えるが、そこまで大きな差が出ることはなく、一番大きな問題はRailsでの開発を支える歴史あるGemの数々である

これには勝てない。Rails脳でいるとあれとこれとあれはGemがあるからとか考えがちだが、ないとなるともうそれは大きな工数がのしかかってくる

やはりこれが一番大きい

RailsでもHanamiのように書けないわけではない。しかしスキャッフォールドはないし、アーキテクチャを支える書き方の制限も設けられていない。自分たちでルールを考え、それを守っていかなければならない

Rails wayは1つのアーキテクチャの選択であり、Railsはそれを支える仕組みを提供している

 

アーキテクチャとは困難な問題にどう立ち向かうのかということだと思う。答えはない。アーキテクチャを決定することをするときにはこうなりましたと完成したものを見せるだけでは足りない。それに加えて、何を参照し、どう考え、どのような選択肢があり、何を諦め、何を選択したのか、そういうことも大事で、残されているべきである

これらを踏まえてすでにアーキテクチャがあるRailsアプリケーションに対していかにアーキテクチャを導入していくかということになる

 

それでは、また