マニュアル: ドメイン駆動設計

投稿日: 更新日:

構成要素

以下「自分なりに」解釈したものを含みます。


基本はこの3つ。

  • Aggregates: 関連するオブジェクトの集まり。
    • 不定数のリストとして表されることもあれば、車のタイヤのように決まった数のオブジェクトをまとめたものもあれば、複数バラバラのインスタンスの寄せ集めのこともある。
    • 要はこれらを抽象化した概念と思われる。
    • 逆に、Entityの特殊なパターンとも考えられそう。
    • 基本的にはルートから操作しないといけない。
      • 実装的には、メンバ変数をそのまま返すことは避ける。あるいは返すとしても、Collection.unmodifiableXXX()などを使って不変にするのが望ましい。
  • Factory
    • インスタンスやインスタンスの集約を生成するクラス。
      • Builderパターンも含まれるため、statelessではない(よって他のものには当てはまらない)。
    • コンストラクタで良い場合の基準が書かれているが、ここは難しいデスネ2
  • Repository
    • DBアクセスを抽象化した「ようなもの」。「ようなもの」と書いているのは、単にSQLを隠蔽するとかというレベルじゃなくて、もっと抽象化されたものとして扱うから。
    • Transactionはこの範囲外と書かれている。

ファクトリの使い分け

個人的にはこれがいいんじゃないかなぁというのを書いてみます。 フレームワークなどで対応している場合は除きます。

  • Value Object: Factory Method
    • 簡潔に書ける、immutable、Flyweightパターンが適用可能だから。
  • Entity: Builder
    • mutableなことが多いため。
  • Repository: Factory Method
    • コンストラクタでもいいですが、テストのことを考えると、インタフェースを作っておいたほうが楽そう。
  • Service: コンストラクタ
    • staticメソッドで書けるケースも多そうですが、慣習として避けたほうがいいかも。
    • Repositoryを内部で持つなら取り替えられる方がいいかなと。。。これは組んでみないとなんとも。

  1. Kindle版の位置No.2525より。 [return]
  2. Kindle版の位置No.3333より。 [return]

外部サイト