ドメイン駆動設計

[ソフトウェア開発,設計]

ドメイン駆動設計

このページでは、ヴァーン・ヴァーノンの著書、「実践ドメイン駆動設計」の抜粋・このWikiの筆者の独断による要約を載せる。

  実践ドメイン駆動設計のAmazonリンク

　実践ドメイン駆動設計 (Object Oriented SELECTION)

  各章抜粋

第１章 DDDへの誘い

• DDDは複雑なシステムほど役に立つ、逆に言えば単純なCRUDが30メソッドほどで作れるようなシステムであればRailsやGrailsを使って終わりでもよい
• ドメインモデル貧血症を防ごう
  • 「すべての振る舞いをサービスに押し込むと、どうしても トランザクションスクリプト になってしまいます。これでは、ドメインモデルのもたらすメリットを失います。」
  • いきなりちょっと難しい。ドメインモデル貧血症とは何か？を端的に言えば、「getter/setterだらけのスクリプトっぽいコード」と言えば伝わるかもしれない。ぼくはよく見たことがある。
• ユビキタス言語を作ろう　→　顧客と開発チームで共有できる語彙を作ろう

第２章 ドメイン、サブドメイン、境界づけられたコンテキスト

• サービスやシステム、事業をドメインとする。その構成要素をサブドメインと考える
• ドメインやサブドメインを考慮し何が課題で何を解決すればいいかちゃんと考えておく、そうせずに設計に入ると無駄や無意味な作業が生まれる
• 同じ語彙を使っていても、コンテキスト（文脈）ごとに異なるオブジェクトがある

第３章 コンテキストマップ

• 外部システムとの連携を境界づけられたコンテキスト同士の通信として検討する（外部IFの考慮）

第４章 アーキテクチャ

• いったん飛ばす

第５章 エンティティ

• 一般的にはテーブルをオブジェクトで表したもの、ORマッピングのクラスたち
• 単なるCRUDツールを作りたい場合、エンティティという概念はそれにそぐわないので注意

• 定義
  • ユニークになるキーが存在する(必ず一意になる)
  • 内部の値が可変
  • ライフサイクル(生成→消滅)がある

第６章 値オブジェクト

• 特徴（定義ではない）
  • テーブルとして存在することがない
  • 値が不変。値の変更がある場合は、新しいものを別に作る必要があり

• 値オブジェクトは永続化してもよい？
  • 書籍の中では永続化の方法はNoSQLなどがよいと書かれている（値オブジェクトは非正規化されているだろうから）
  • 永続化したからと言って、値オブジェクトがエンティティになるわけではない

• ビジネスロジック
  • もっともビジネスロジック（アルゴリズム要素）が書きやすい場所のように思う
  • 値オブジェクトの概念が無ければビジネスロジックがトランザクションスクリプトになってしまい、可読性が悪くなる

• 値オブジェクト(ValueObject)でバグのない開発を
  • 設計要件をギッチギチに詰めたValueObjectで低凝集クラスを爆殺する
  • DDD に入門するなら、まずは ValueObject だけでもいいんじゃない？
    • ValueObjectの設計・コーディングのやり方
  • 大失敗した設計、そしてドメイン駆動設計の基本に立ち返る
    • DAO/DTOを使ってドメインモデル貧血症になったのでValueObjectを採用する話

第７章 サービス

• エンティティでも値オブジェクトでもないという根拠は何？どういうときに使える？
  • 重要なビジネスロジックである
  • ドメインオブジェクトを変換する処理である
  • 複数のドメインオブジェクトを合算して、値を算出する

• 使い過ぎに注意
  • 使い過ぎるとドメインモデル貧血症を起こし、トランザクションスクリプト祭りになりクソコードになる

• 状態を持ってはいけない、ステートレス
  • サービス内部に状態を持たせてはいけない、これは当たり前か

第８章 ドメインイベント

いろいろあるのだが、いったん飛ばす

第９章 モジュール

名前空間のこと、Javaだとpackage

第１０章 集約

この章は単一の要素についての話ではなく、要素を集約した際のベストプラクティス集のような感じ。あとでまとめる。

第１１章 ファクトリ

オブジェクトを有効に生成するための方法

第１２章 リポジトリ

• リポジトリの実装スタイル
  • リポジトリはコレクション指向（DB操作を隠蔽し、JavaのListやSetのようなインターフェースでデータを操作する）で作るべし
  • ただし、それが目的にそぐわない場合永続指向（DB操作は隠蔽せず、saveなどのインターフェースを使う）で作ることも可能
    • NoSQLはどうしてもコレクション指向にできないので、永続指向になる

• リポジトリの実装におけるアンチパターン
  • やはりお前たちのRepositoryは間違っている

• 下記の人はもっぱら永続指向で作るべきと書いてる、そうだろうか？
  • 参考: 私的実践DDD、その２

• DAOとリポジトリの違い
  • リポジトリとDAOの住み分け方

  面白そうだったトピック

ドメイン駆動設計におけるドメインモデルとリポジトリの関係

• ドメインモデルにリポジトリの操作やリポジトリに依存するコードを書いてもいいか？
  • DDD的にはそれはどちらでもOK、ドメイン設計とドメインモデルを区別せよ

   ドメインモデルは実装に落とし込む中で必然的にドメイン設計を必要としますから、
   ドメインモデルの中にファクトリやリポジトリを含むオブジェクト生成／永続化のコードが入ってくること自体はDDDとしては問題ないです。
   ただし、それはドメインモデルの要素ではありません（つまりビジネスの関心事ではなくソフトウェアの関心事である）から、
   何らかの形で純粋にドメイン設計の部分をドメインモデルから区別できるようにコーディングすることは重要です。

DDD(ドメイン駆動設計)における、マスタ情報の扱い

• ValueObjectとEntityの定義＆実装がごっちゃになっている
• 個人的にはValueObject -(依存)-> Entityだと思うのだが、逆だとダメじゃないのか