FreeStyleWiki

ドメイン駆動設計

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

ドメイン駆動設計

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

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

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

  各章抜粋

第1章 DDDへの誘い

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

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

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

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

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

第4章 アーキテクチャ

  • いったん飛ばす

第5章 エンティティ

  • 一般的にはテーブルをオブジェクトで表したもの、ORマッピングのクラスたち
  • 単なるCRUDツールを作りたい場合、エンティティという概念はそれにそぐわないので注意
  • 定義
    • ユニークになるキーが存在する(必ず一意になる)
    • 内部の値が可変
    • ライフサイクル(生成→消滅)がある

第6章 値オブジェクト

  • 特徴(定義ではない)
    • テーブルとして存在することがない
    • 値が不変。値の変更がある場合は、新しいものを別に作る必要があり
  • 値オブジェクトは永続化してもよい?
    • 書籍の中では永続化の方法はNoSQLなどがよいと書かれている(値オブジェクトは非正規化されているだろうから)
    • 永続化したからと言って、値オブジェクトがエンティティになるわけではない
  • ビジネスロジック
    • もっともビジネスロジック(アルゴリズム要素)が書きやすい場所のように思う
    • 値オブジェクトの概念が無ければビジネスロジックがトランザクションスクリプトになってしまい、可読性が悪くなる

第7章 サービス

  • エンティティでも値オブジェクトでもないという根拠は何?どういうときに使える?
    • 重要なビジネスロジックである
    • ドメインオブジェクトを変換する処理である
    • 複数のドメインオブジェクトを合算して、値を算出する
  • 使い過ぎに注意
  • 状態を持ってはいけない、ステートレス
    • サービス内部に状態を持たせてはいけない、これは当たり前か

第8章 ドメインイベント

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

第9章 モジュール

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

第10章 集約

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

第11章 ファクトリ

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

第12章 リポジトリ

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

  面白そうだったトピック

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

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

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

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