refirio.org

より良い設計をするために

Laravelでウェブアプリケーションをつくるときのベストプラクティスを探る - Qiita http://qiita.com/nunulk/items/b1e2da51b5dabab92da0 Laravel5のアーキテクチャから学ぶより良いクラス設計 - Qiita http://qiita.com/nunulk/items/2c637d3952096ef74677 LaravelのORMで初心者から職人へ - Qiita http://qiita.com/henriquebremenkanp/items/cd13944b0281297217a9 Laravel Recipes日本語版 http://recipes.laravel.jp/ Laravel リファレンス https://book.impress.co.jp/books/1114101107 https://github.com/laravel-jp-reference/chapter8 ■Laravel経験者に話を聞いたときのメモ（2017/09/13） ・バージョン5.4を採用した ・Homesteadはあくまでも開発環境用として使った。本番環境はEC2にPHPなどをインストールして構築した ・本番反映は「デプロイ → マイグレーション → シード」を実行 ・基本構成は MVC + Service + Repository ・DIとEloquentには慣れが必要だった ・「php artisan make:auth」を使うとカラム名の変更などが大変なので、認証はmiddlewareを使って一から作った ■追加考察メモ ・リポジトリのContractsは、個別に作るよりも「DatabaseRepository」というインターフェースに統一する方がいいか これでもテスト時にリポジトリを差し替えたりは支障ないはず と思ったが、DIではContractsを注入するので共通のDBインターフェースにするのはまずいかも AppServiceProviderで関連付けも行っている サービスからリポジトリを呼ぶとき、実態を直接呼ばずにContractsを呼ぶべきかも ・APIなどを使う場合、サービス内に直接接続処理を書かずにリポジトリ内で処理するか ・サービスはドメイン駆動設計をもとに、リポジトリはデータベースや相手APIの仕様をもとにするか