DDD は『複雑なドメインを共通言語で扱う』ためのアプローチ
DDD は Eric Evans によって提唱された、ビジネスドメインの複雑性に立ち向かう設計手法です。本記事では編集部の視点で、戦略設計と戦術設計を公開情報をもとに整理します。マイクロサービス設計 もご参考に。
戦略設計の3要素
(1) Ubiquitous Language (ユビキタス言語)：ドメインエキスパートとエンジニアの共通言語。(2) Bounded Context (境界づけられた文脈)：用語の意味が一貫するスコープ。(3) Context Map：複数の Bounded Context の関係。(4) Subdomain：Core / Supporting / Generic に分類。(5) 言語の境界 = システムの境界。
Bounded Context 間の関係
(1) Partnership：両者が協力して進化。(2) Shared Kernel：共通モデルを共有(注意して)。(3) Customer/Supplier：上流下流の関係。(4) Conformist：上流に従う。(5) Anti-Corruption Layer：腐敗防止層。マイクロサービスの境界設計とも密接です。
戦術設計のパターン
(1) Entity：ID で識別される。(2) Value Object：値で識別、不変。(3) Aggregate：整合性境界。Aggregate Root を通じてアクセス。(4) Repository：永続化の抽象。(5) Domain Service / Application Service：振る舞いの置き場。
実装パターン
(1) Layered Architecture：Presentation/Application/Domain/Infrastructure。(2) Hexagonal Architecture：ポート＆アダプター。(3) Onion / Clean Architecture：依存関係を内側に。(4) CQRS：読み書きの分離。(5) Event Sourcing：状態をイベントで構築。イベント駆動アーキテクチャ もご参考に。
導入する/しないの判断
(1) ドメインが複雑か：CRUD 中心なら不要。(2) ビジネス変化が早いか：DDD の効果大。(3) チーム規模：5名以上で本領発揮。(4) 長期保守：3年以上の継続が見込めるか。(5) 段階的導入：戦略設計だけ取り入れる選択肢。
失敗しがちなパターン
(1) 戦術パターンの形だけ導入：本質を捉え損ねる。(2) Entity と DTO の混同：ドメインが貧弱化。(3) Aggregate を大きく作りすぎ：パフォーマンス悪化。(4) ユビキタス言語を作らない：技術用語が氾濫。(5) 全システムで DDD 適用：シンプル領域には過剰。対策は、(1)戦略設計から、(2)ドメインモデルとDTOの分離、(3)Aggregate最小、(4)用語集メンテ、(5)Core領域に限定、です。