ディレクトリの分け方
タイトル悪いので後で直す
>どっちのディレクトリ構造が良い？
>
>技術駆動パッケージング」というアンチパターン。設計パターンごとにまとめるのは一見綺麗に整頓されているように見えるが、ドメインの関心事が設計パターンで分断されてしまい、業務概念ごとにまとまるべきものが低凝集になってしまう。特にマイクロサービス化を試みる場合非常に困る。
>
↑ずっとこのツイート（の引用先）を探してた
機能を構成に依存させないで引用したかったんだよな
なんか「業務」と「関心」と呼ぶのは間違っていると思う
右は、フレームワークが要求する構成
業務にも関心があるのだから、関心と呼ぶのは変だ
関心じゃなくて、レイヤーとかだろう
後者が意外と多いのが怖い
>前から思ってること。
>プログラムのクラスなどをパッケージやフォルダ分けするときの分類方法に「縦割り」と「横割り」があって自分は「縦割り」が好きなんだけど、世の中「横割り」が主流なような気がする。なぜなんだろう？
>横割りはデメリットが多く、縦割りの方が優れていると思うのだが…
>
２つの切り口において、リポジトリ全体を確認せずに第一階層しかみないから後者の人気が微妙に出てしまうのでは？
Railsとかが右になってるからでは？
>PBF(Package by Feature), no more PBL(Package by Layer)
この名前はわかりやすい
業務というよりFeatureだよな
業務でFeatureを実装してるだけ
どっちが好き、嫌いで考えるのはおかしくて、現在や将来楽ができるのはどっちなのかを考えるべき
既存のフレームワークがたまたま右の構成で新規作成するようになっているだけ
フレームワークを使ってもらう観点では、右のほうがわかりやすいから
コントローラどこに書けばいいの？→ここか！ってなる
また、そもそもフレームワークを作った人もそこまで考えてなかった可能性もある
フレームワークを作るということは、まだまだ設計についで議論が煮詰まっていない時代だから
プロジェクト初期においては右、というのは多少は許せるが、じゃあ右から左の設計に切り替える判断をできる人間が常に居ないと苦しむことになるが大丈夫か、と思う
しかもそのタイミングにおいて、締め切りに追われてないとか
これの話題で要はバランスおじさんされると非常にむかつく
ここらへんをいい感じに左に持っていくには、多分リポジトリの整頓具合、リファクタリングの筋道も見据えて説得するのが良い
ドメインごとに分けて作れば、そもそもドメイン内が多少ごちゃごちゃしてても直しやすい
あとから構造化できる
もしもコントローラとかサービスがバラバラだとそれが面倒
インフラストラクチャ駆動パッケージング
ぐぐったらエヴァンスの本とかが出てくる
linuxとかのOSのFilesystem Hierarchy Standardは、実はこのアンチパターンを踏んでいる
だからこそOSまるごとをパッケージするというdockerが欲しがられる
OSのライブラリは、複数の箇所に分散して何かを配置するのではなく、ライブラリが一つのフォルダにまとめられて、その中にlibとかbinとかがあるべき
あと、こういう面倒くささが発生してしまうのは、ファイルをフォルダにしまわないといけないからで
エディタの支援と、ファイル内にメタデータをアノテーションする形で全部フラットに配置するのもありだと思う
ファイル名を規則的にしたくなって、結果的にフォルダを作るのと同じような面倒は発生しそうだが
結合度と凝集度の話っぽい