設計レビューで見ているポイント

設計レビューでよく止まるのは、こういう状態です。

• どこに何を書くべきかが曖昧

• 処理の意図が読み取れない

• 変更したときの影響範囲が見えない

こういうコードはだいたい共通していて
👉 構造として整理されていない

なぜ起きるのか

理由はシンプルです。

1. 実装優先で進めてしまう
   ・とりあえずControllerに書く
   ・動いたらそのまま

2. 責務の基準が曖昧
   ・Serviceの役割が人によって違う
   ・Repositoryが何でも屋になる

3. レビュー観点が共有されていない
   ・人によって「良い設計」の基準が違う

設計レビューの観点

設計レビューではいろいろな観点を見ています。

• 仕様と整合しているか

• エラー時に壊れないか

• パフォーマンスに問題ないか

• 運用できるか

ただ、実務でレビューしていると最終的に「責務が正しく分かれているか」に集約されます

分離の考え方

レビューでは「その処理はどこに置くべきか？」を軸に見ています

ざっくり分けると

• Controller：入口・出口（HTTP）

• Service（UseCase）：処理の流れ

• Repository / Query：データ操作

ここが崩れると

• 可読性が落ちる

• バグが増える

• 修正が怖くなる

どこで分けるべきか

■ Controller

• 業務ロジックを書いていないか

• 分岐やループが多くないか

■ Service（UseCase）

• 1つのユースケースにまとまっているか

• 処理の流れが読みやすいか

■ Repository / Query

• データ操作だけに責務が限定されているか

• ビジネスロジックが混ざっていないか

命名

• 名前で処理内容が伝わるか

👉 名前で理解できない設計はレビューできない

NG例

❌ Controllerにロジック集中

public function store(Request $request)
{
    $user = User::find($request->user_id);

    if ($user->isActive()) {
        Order::create([...]);
    }
}

❌ Serviceがただの中継

class OrderService {
    public function create() {
        return $this->repository->create();
    }
}

❌ Repositoryにロジック侵食

public function getActiveUsers()
{
    return User::all()->filter(fn($u) => $u->isActive());
}

まとめ

設計レビューでは色々な観点を見ますが、
実務ではほぼこれに集約されます👇

• 責務が分離されているか

• 処理の意図が読み取れるか

• 変更に耐えられる構造か

そして一番大事なのはこれ
👉 「その設計、現場で運用し続けられる？」