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