アーキテクチャの記事
- CQRSを小さく始める — 検索はRepositoryでなくクエリクラスに 画面や API が増えるたびに Repository へ検索メソッドを足していくと、集約を守るためのクラスが表示の都合で膨らみます。DB もテーブルも分けず、読み取りを用途ごとのクエリクラスに切り出すところから CQRS を始める設計と、その先へ進む条件を Laravel の例でまとめます。
- ドメインイベントで副作用を分離する — 通知と集計を本体から外す 注文の確定に通知メール・売上の集計・キャッシュの削除を足していくと、UseCase が膨らみ、副作用の失敗や遅さが本体の失敗になります。ドメインイベントで副作用を切り離し、同期と非同期をハンドラーごとに決める設計と、イベントにしないものの見分け方を Laravel の例でまとめます。
- 集約の境界をどこで切るか — トランザクションの範囲から考える 集約を大きくしすぎると無関係な更新どうしが衝突し、小さくしすぎると守りたいルールを守れなくなります。「コミットの瞬間に一緒に正しくなければならないルール」から集約の境界を決め、外の集約は ID で参照する設計を、注文・明細・在庫の例でまとめます。
- Value Objectで「不正な値が存在しない」状態を作る — 検証を型に閉じ込める 金額や期間を int や string のまま扱うと、検証が呼び出し側に散らばり、どこで検証済みなのか分からなくなります。生成時に検証する Value Object で不正な値を作れなくする設計と、等価性・不変性の扱い、やりすぎになる境界をまとめます。
- コードレビューで見ている9つの観点と、Must / Should / Mayの付け方 コードレビューは書き方の好みを揃える場ではなく、本番で壊れないかを確かめる場です。要件・責務・境界条件・整合性・冪等性・後方互換性など、私がレビューで確認している観点と、指摘の優先度の付け方をまとめます。
- DBとS3をまたぐ更新で、整合性の責任をどこに置くか DBのレコードとS3のファイルを一緒に更新する処理は、片方だけ成功すると不整合が残ります。呼び出し側に後始末を任せず、Repositoryなどの境界に整合性維持の責務を持たせる設計と、失敗時の順序の考え方をまとめます。
- $order->status = 'confirmed' と書かない理由 — 状態変更の責任をオブジェクトに持たせる 外からプロパティを書き換える設計では、状態遷移のルールが呼び出し側に散らばります。confirm() のような振る舞いに状態変更を閉じ込め、不変条件をオブジェクト自身に守らせる設計と、そのトレードオフを解説します。