🌊
ドメインオブジェクトが適切に抽象化され、アプリケーション層と適切に分離されているか？
ドメインオブジェクトが適切に抽象化され、アプリケーション層と適切に分離されているか？
背景・概要
ドメインモデルは、業務ルールを正しく表現・保守しやすくする中核的存在
プレゼンテーションやアプリケーション層と混在せず、明確に分離・責務分担されていることが拡張性・変更耐性に直結する
例
- Task, Document, UserRoleなどのドメインがアプリ層から独立している
- ユースケース層(Application Service)がドメインサービスを利用して業務ロジックを実行
- ドメイン層にだけ isOverdue, canApprove のような業務判断ロジックが存在する。また判断ロジックは振る舞いの中で使用するprivate関数が望ましい
よくある失敗例
- フロントのDTOとドメインモデルが混在し、意図しない振る舞いを起こす
- Application Serviceに「金額計算」「ステータス判断」などが記述され、再利用できない
- ドメイン層がインフラ層のライブラリやDB型に依存しておりテスト不能
FAQ
Q. DTOやAPIモデルとは何が違う？
A. ドメインモデルは業務判断に必要な情報と振る舞いを持ち、表示や通信のための形には縛られないもの
Q. 小さいシステムでもドメイン層を分けるべき？
A. 将来の保守性やテスト性を考えると、最初から分離しておくと後で楽になるかな
関連観点
📘 本記事は SaaS設計レビュー観点チェックリスト（2025年版） の一部です。
設計観点カテゴリ：🏷️ドメイン
レベル：Structure（構造・原則・責務整理レベル）
推奨読者：設計初心者 / 設計中のチーム / レビュワー
🧭 他の観点もまとめて読みたい方はこちらからどうぞ。
Discussion