最近の仕事で思うのがソースが一箇所に集中しつつありながらもちょっとマイクロサービス意識して別アプリケーションのディレクトリ切ってみて結果的にソースや設計思想も散らばってて辛いというのがあるのでどう分割すると良さそうなのかというのを考えてみた
zennでモノレポの記事漁っててHimenonさんの記事がまとまってて結構すき
(記事移動先: https://himenon.github.io/docs/javascript/comparison-of-package-layout)
Himenonさんの記事にない個人的なGood / Bad述べると(似たような意見になるかもしれない)
Good
Bad
同様に個人的なGood / Bad述べると
Good
Bad
アプリーケーション複数になった場合、Modelだけは様々な箇所で使いたがるものであると思っていたり、ライブラリの更新の際もModel、View側どちらかが起因で更新難しいかの切り分けをしやすそうと思っている
IDEの恩恵を得られにくいView側のヘルパー関数が非推奨になり更新したくてもできないという経験もあったりした
Viewの観点でいうとViewの役割果たさなくてもよいというのもあるのでModelとControllerのみ扱うようにし、できるだけアプリケーションという単位で抑えて分離させないというのもアリ
別アプリケーション切って同じようなModelを作成するというのがやりたくないことだったりする
モノレポ構成を意識した下記のプロジェクトを作成した
coreではModelやビジネスロジック等扱い、wwwではroutes, Controllerのみを使用するような想定で作成している
composerの仕組み上の話になるが
{
    "name": "projects/core",
    "type": "library",
    ...
}
{
    ...
    "repositories": [
        {
            "type": "path",
            "url": "../cakephp_debug_sample_projects_core",
            "options": {
                "symlink": false
            }
        }
    ],
    "require": {
        ...
        "projects/core": "dev-main"
    },
    ...
}
とライブラリの設定をし
www/src/Controller/PagesController.php
のような感覚でwww側のリソースでもcore側によるModelの処理を読み込んでいる
過去記事でも触れてるやつ
ちょっとしたUI調整のときのみに動かしたいCIタスクが多くあるのでモノリスだとあまりやりたがらない部分だったりする
過去記事でも触れてるやつ
宗教的なものだが一定のコーディングの統一化をすべてのプロジェクトに対して適応が可能なのでコンテキストを合わせやすくなりそう
過去記事でちょっとだけ触れてる
パス指定による共通のビルド・テスト設定の読み込みが可能だとモノレポ間でも設定に困るということは少なくなる