Laravel / PHPの記事
- Facadeを使わずDIで書くと何が変わるか — 見える依存と使ってよい場所 Laravel の Facade やヘルパーは短く書けて、テスト用の fake も揃っています。それでも UseCase では使わず、コンストラクタで依存を受け取る理由を、依存の見え方・テストの範囲・時計とトランザクションの抽象の作り方から整理し、Facade を使ってよい場所との線引きをまとめます。
- Http::fakeで外部APIの障害を再現する — タイムアウト・5xx・遅延のテスト 外部APIの呼び出しは、成功の場合しかテストされていないことがよくあります。LaravelのHttp::fakeで、タイムアウト・5xx・429・形の違う応答を再現し、リトライするか・利用者に何を返すかという設計の判断をテストに残す書き方をまとめます。
- FormRequestとUseCaseで入力検証をどう分担するか 入力検証を FormRequest に寄せすぎると HTTP 以外の経路で漏れ、UseCase に寄せすぎると利用者に分かりやすいエラーを返せません。形式・値の不変条件・状態に依存するルールの3つに分けて置き場所を決める設計を、Laravel の例でまとめます。
- Laravelのジョブをコミット後に実行する — afterCommitとOutboxの使い分け トランザクションの中でディスパッチしたジョブやイベントは、コミットより先に動いたり、ロールバックされた処理の後続として動いたりします。Laravel の after_commit で順序をそろえる方法と、それでも残る「コミット後に依頼が消える」問題への Outbox での対処をまとめます。
- Laravelのキュージョブを冪等にする — uniqueジョブに頼らない設計 Laravelのキュージョブは、リトライやタイムアウト、ワーカーの停止で同じジョブが2回実行されることがあります。ShouldBeUniqueやWithoutOverlappingで防げる範囲と防げない範囲を整理し、ジョブ自体を冪等にする設計をまとめます。
- Laravelを使うが、ビジネスロジックをLaravelに支配させない Controller・Fat Model・Facade・Eloquentへの依存が積み重なると、Laravelアプリは変更に弱くなります。UseCase・Domain・Repositoryに責務を分け、フレームワークを「外側」に置く設計の考え方と、やりすぎになる境界をまとめます。
- Repository InterfaceとDTOでEloquentから業務ロジックを切り離す Eloquentのモデルをそのまま業務ロジックに渡すと、永続化の都合がロジックに漏れ出します。Repository InterfaceとDTOで境界を引く設計の具体例と、手間に見合わないケースの見分け方を解説します。
- テストは「将来壊してはいけないもの」を書き残すもの — LaravelのFeature Test中心の考え方 テストの数やカバレッジを目的にすると、守るべきものが見えなくなります。LaravelではFeature Testを中心に据え、複雑なルールにだけUnit Testを足す考え方と、境界値・異常系・冪等性・認可など重点的に書く観点をまとめます。