🏗️ 設計判断を属人化させないために、DDDの判断フローをWebアプリにしてみた
一言で言うと
ドメイン駆動設計（DDD）における「設計判断の流れ」を、誰でも同じ条件からたどれるWebアプリ「Design Decision Toolkit」を作った、という記事です。
解決したい課題
- 設計判断（例：「今回はドメインモデルを作りましょうか」「CQRSは不要」等）を口頭で共有しても、後から再利用できない
- 判断の背景や分岐条件が抜け落ちているため、別の人が同じ判断をしようとすると詰まる
- 「どの条件を見て、どの選択肢を外し、どの状態になったら再検討するのか」という判断の流れが記録されていない
設計判断が口頭・ドキュメントだけで伝わらない理由
- 条件によって判断が分岐するため、文章化すると長く複雑になる
- 似た方式でも、採用条件と非採用条件が違う
- 読み手の状況によって必要な詳細度が変わる
- 長いドキュメントは必要な場面で読まれず、結局詳しい人への確認に戻る
Design Decision Toolkit の2つの入口
1. 設計方式判断（新規開発向け）
これから方式を決めるときに使う。以下の観点を順に確認：
- その機能が顧客の選択理由や収益性に直接影響するか
- データ構造や業務ルールが単純か複雑か
- 現在値だけで判断できるか、過去の順番が必要か
- 読み取りと書き込みを分ける必要があるか
- どのテスト方針で守るべきか
2. 設計変更診断（既存設計の見直し向け）
すでに動いている設計に違和感が出てきた時に使う。入口は現場の課題：
- 業務ルール変更時に修正箇所を把握しきれない
- 検索・一覧・集計が目標時間に収まらない
- 外部送信の失敗対応が手作業では回らなくなっている
- 内部モデルを変更すると公開APIまで変わってしまう
判断フローで守った設計方針
① 用語ではなく、観察できる事実から始める
最初の選択肢では方式名を出さない。「中核領域か」と聞く前に、顧客が選ぶ理由や収益性への影響を確認。DDDの用語を知らなくても答えられる状態を作る。
② 重い方式をすぐには提案しない
ドメインモデル、CQRS、イベント履歴式ドメインモデルなど影響範囲の大きい方式は、導入条件を外すと負債になる。検索が遅い場合でも最初はSQL、インデックス、ページング等の確認から入り、CQRSは最終候補。
③ 非採用案と再検討条件も出す
- なぜ別の方式を採用しなかったのか
- いまは過剰だと判断した理由
- どの条件が変わったら再検討するのか
実装アーキテクチャ
- 静的Webアプリ（HTML、CSS、vanilla JavaScript）
- フローチャート: SVG直接描画
- コードハイライト: highlight.js
- 処理シーケンス: Mermaid
- バックエンド、DB、認証なし（判断ロジックが決定的でサーバー側状態が不要）
- 結果はMarkdownメモとしてコピー可能（ADRやタスク分解の下書きに）