はじめに
クオカードのコーディングテスト（書籍管理システムのWeb API開発）を題材に、DDD（ドメイン駆動設計）の考え方を意識して設計書をどうまとめるかを整理してみました。
まだまだ学んでいる途中ですが、自分なりに「こういう構成なら整理しやすい」と思った流れをまとめています。
なぜDDD視点の設計書が求められるのか？
DDDの特徴は、「ソフトウェアの構造を現実の業務やビジネスルールに近づけること」です。
設計書においても、単なるAPI仕様やER図の羅列ではなく、
- ビジネス用語（ユビキタス言語）で構造を説明できているか
- 責務や境界（どこで何を守るか）を明確に示しているか
- 将来的な拡張や仕様変更への柔軟性を考えているか
といった観点が大事だと感じています。
こういった部分を意識することで、システム全体の品質や見通しの良さが変わってきます。
設計書の構成例（DDDの視点を活かすための章立て）
以下は設計書を作る際に決めることです。
ドメイン概要・ユースケース
最初に、対象となる業務ドメインの全体像や「何を実現したいのか」を簡単にまとめます。
例：
- 「書籍管理システムでは、書籍と著者を登録・検索できる」
- 「著者と書籍の関係性を管理し、後から本の一覧や著者情報を参照できる」
ここで**ユーザー視点の業務シナリオ（ユースケース）**を具体的に書き出しておくと、その後の整理が楽になります。
ユビキタス言語（用語集）
ユビキタス言語はDDDにおいて重要な概念で、用語の認識のずれや意味がぶれないように、主要なビジネス用語やモデル名の定義を明確にしておきます。
例：
- Book（書籍）：ISBN、タイトル、著者IDを持つエンティティ
- Author（著者）：氏名、著書リストを持つエンティティ
この部分を設計書の冒頭に用語集として載せると、以降の説明が分かりやすくなります。
ドメインモデル設計
エンティティ・値オブジェクト・集約といったDDDの設計要素に沿って、重要なデータ構造を図やテーブルで整理します。
- Book（エンティティ）：ID、タイトル、出版日 など
- Author（エンティティ）：ID、氏名、プロフィール
- BookTitle（値オブジェクト）：タイトル名、バリデーションルール（空や重複の禁止など）
集約の単位や、集約間の関係性も簡潔に明記します。
境界づけと責務の整理
DDDでは、「どのクラス・レイヤーが何を守るか」が明確になっていることが大切です。
- Bookは自身のタイトルや出版日に対するバリデーションを責務とする
- 著者が削除された場合の挙動（著書への影響）はドメインサービスで定義する
- Repositoryは永続化・取得のみを担い、ビジネスロジックは持たない
こうした責任範囲や設計判断の意図も文章で簡単にまとめておきます。
アーキテクチャ全体像
クリーンアーキテクチャやオニオンアーキテクチャなど、プロジェクト全体のレイヤー構造や依存関係のルールを図で示します。
例：
- ドメイン層（モデル、サービス）
- アプリケーション層（ユースケース）
- インフラ層（DB・外部API連携）
- プレゼンテーション層（Controller, DTO）
どのレイヤーがどこに依存するかを明確にし、テストや保守のしやすさも意識した構成を考えます。
API設計とDTO設計
API仕様の羅列だけでなく、
ドメインモデルとAPIモデル（DTO）の対応関係も整理します。
- /books/{id} のレスポンスDTOはBookエンティティとどうマッピングされるか
- Controller層でDTO→ドメインモデル、ドメインモデル→DTOの変換をどう担保するか
業務ロジックとAPI入出力の分離が明確になります。
テスト設計の方針
ドメイン層のテスト対象や範囲も大事です。
- BookやAuthorのドメインロジック（タイトルバリデーションなど）の単体テスト
- Repository層のテスト（MockやインメモリDBの活用）
- Controller/API層の結合テスト方針
テストしやすい設計かどうかも設計段階で確認しておきます。
テーブル設計・スキーマ設計
DBのテーブル設計もドメインモデルに合わせて行います。
- authors, books テーブルの主キー・外部キー設計
- データ不整合を防ぐ方法や、削除時の制約など
**「なぜこのカラム構成なのか」**まで意識しておくと、あとから自分でも見返しやすいです。
今後の拡張や注意点
最後に、「仕様変更・拡張が発生した場合の注意点」や、業務理解の前提条件などもまとめておきます。(今回は題材があるので以下は一例です)
- 出版社やジャンル管理を追加したい場合の拡張方針
- 既存機能への影響や、安全に変更するためのポイント
おわりに
設計書は「相手にシステムの全体像や設計の意図を伝えるためのツール」です。
DDDの視点を取り入れることで、単なる技術仕様の羅列ではなく、業務とソフトウェアがしっかり結びついた設計書を目指せると思います。
設計書があると実装後のテストや保守、機能追加の際にも見通しが良くなります。
自分の頭を整理する意味でも、こういった流れで設計書を書いてみるのはおすすめです。
コメント