17件のドキュメント
業務ロジックはドメインオブジェクトに書く
サービス層を薄いオーケストレーターに保ち、業務ロジックはそのデータを持つドメインオブジェクトに集める行動規範
区分オブジェクト
ステータス・種別などの区分値を、固有ロジックを持つオブジェクトとして表現しswitch文の散在を防ぐパターン
ドメインオブジェクトへの業務ロジック集約
業務ロジックをデータを保持するドメインオブジェクト自身に持たせ、貧血ドメインモデルを避ける設計方針
不正な状態を型で表現不可能にする
ドメインオブジェクト設計時、存在してはいけない状態をコードで表現できないようにする設計規範
ファーストクラスコレクション（コレクションオブジェクト）
コレクションを専用クラスでラップし、そのコレクション固有の業務ロジックをメソッドとして持たせるパターン
薄いサービス層パターン（Application Service）
アプリケーションサービスをオーケストレーターに徹させ、業務ロジックを持たせないことでユースケースを読みやすく保つパターン
三層分離パターン（ドメイン・アプリケーション・インフラストラクチャ）
ソフトウェアをドメイン・アプリ・インフラの3層に分離し、業務ロジックを技術的詳細から独立させるアーキテクチャパターン
設計はドメインモデルから始める
DBやAPI設計より先に業務の言葉・ルール・概念を整理し、技術的都合でドメインモデルが歪むことを防ぐ行動規範
ドメインモデル抽出スキル
業務の言葉・ルールからドメインオブジェクトとその関係を発見し、設計の出発点となるモデルを作る実践手順
段階的リファクタリング戦略
既存コードを壊さずにドメインオブジェクト設計へ移行するための段階的な手順
型駆動設計（Type-Driven Design）
ドメインの制約・状態・ルールを型システムで表現し、不正な状態をコンパイル時に防ぐ設計手法
値オブジェクト（Value Object）
ビジネス上の意味を持つ値を専用クラスで表現し、制約・操作を型に閉じ込める設計パターン
プリミティブ執着（Primitive Obsession）
ドメイン概念をプリミティブ型で直接表現し続け、業務制約・操作がコード中に散らばるアンチパターン
状態フラグ・汎用テーブルのアンチパターン
DBスキーマで状態を複数フラグ列や汎用コードで表現し、不正な状態の組み合わせを許容してしまう設計の問題
DDDはなぜ必要か
ドメイン駆動設計の目的は「業務の複雑さをソフトウェアで正確に表現し、変化に耐える設計を維持すること」
ユビキタス言語
開発者とドメインエキスパートが共有する、コード・会話・ドキュメントすべてに貫徹させる共通言語
境界づけられたコンテキスト
ドメインモデルが一貫した意味を持つ明示的な境界。コンテキスト内ではユビキタス言語が統一される