この記事は？
この雛形を使用した開発が一旦区切りがついたので、素のlaravelと比較しながら感想を述べたもの
これを使用して社内の標準化を進めているので、それの役に立てば良いなという思いも
素のlaravelとの比較・利点など
詳しくは上記の記事に書いてあるので、自分が触れたところをざっくりという感じです
Clientとapiのソースが完全に分けられている
Client側を気軽に入れ替えやすい
今はvue2系を使用しているが、今後reactやらモダンなフロント言語に移行しやすいので今後も長く使えるのかなあと思った
ドメイン駆動設計
ドメイン駆動設計。データベースのロジックが複雑なシステムに向いている気がする
presentation層の半自動化
Swaggerを使ってAPIの設計書を作成 jsonファイルで作成するが、
そのファイルを参照してrequest,resource,controller,routeをある程度作成してくれる
(ただし、Controllerはおまけ程度、名称など指定できない)
素のlaravelだと、make::〇〇コマンドを作成する分叩かないといけないので、作業効率が上がっている（もちろん、中身などはある程度作成しないといけないが）
migrationがflyway
DBのlaravel依存を減らせていて、疎結合になっている
doctrineを使用したxmlマッピング
ドメイン層とrepository周りのインフラストラクチャ層の分離のために使用、ファイルの数は増加する
buildツール完備
一個叩くだけでコーディング規約のチェック、テストなどが一気に通るので効率化につながっていると思う。
他人の作業ブランチにpushする前にこのコマンドを通してしまい、競合が約200件とかになってしまうということもあるので使い方に注意する
開発してみて気づいた欠点など
DB周りの実装の重さ
機能的比較で述べたように、controllerやrequest周りはある程度自動で作成されるが、service、domain、doctrineのxmlマッピング、インフラ層、SQLの実装などがあり、どうしてもlaravel標準のeloquentなどに比べると、実装に時間がかかるという感覚
特に、ドメイン層、doctrine周りの実装に時間がかかり、doctrine周りは学習コストも高めなのでより顕著
疎結合にするためにはしょうがないとはいえ、手打ちでの実装箇所が多くなるにつれて、タイポなどの些細なミスが増えてくるので、エラーが頻発して精神的に苦しい場面はあった
ドメイン層も対象となるテーブルが多くなったり、ロジックが複雑になったりすると、コーディングの負担が多くなる。しかし一旦作成してしまえば、軽微な仕様変更等にもある程度対応できるのでそこまででもない、継続的な開発に真価を発揮するのかもしれない
client層のAtomicDesign周りに苦労
clientにはvue2系を使用して、AtomicDesignを使用しているが、それに対する学習コストも発生するので大変
特に開発初期はコンポーネントの数も少なく、AtomicDesignの意義が感じにくい
画面数がwebサイト並に多かったり、画面表示も凝って整えるのであれば話は別だが、機能ありきのシステムにこの設計手法を導入するメリットはあまり感じられないかなと思った。
キャッチアップの難しさ
素のlaravelも同様であるが、レイヤーなどの構造が理解しにくい
これにドメイン駆動設計の要素やdoctrineやflyway、client周りの学習も入ってくるので、余計初期のキャッチアップが困難 laravelを使用した開発を行っていたのであれば、追加された機能やパッケージについて学習するだけで済むが、今後これを社内の開発基盤にしていくのであれば、学習コストがかかるということは意識するべき
別案での標準化検討
特に致命的なデメリットは感じられないので、機能的にはこのまま進めるべきだと思った
強いて言うならDB周りの実装が軽くなるツールがあればそれに乗り換えてもよいと考える
強化案
doctrineやドメイン層周りの実装の重さの改善が欲しいと思った
swaggerのapi自動作成のような、ドメインの設計を記述したjsonファイルを元にドメインのphpファイルとそれに対応するテーブルのマッピングを記述したxmlを自動作成するコマンドを作成中しているので、それが完全になれば開発速度が大幅に向上すると思う
まとめ
実際開発してみて、素のlaravelより学習コストは高くなるが、非常に堅実な開発ができると思った
この開発基盤の社内標準化に向けて、色々調査や改善をしていきたい