- 作者: ヴァーン・ヴァーノン
- 出版社/メーカー: 翔泳社
- 発売日: 2015/03/19
- メディア: Kindle版
- この商品を含むブログ (1件) を見る
- 作者: Eric Evans
- 出版社/メーカー: 翔泳社
- 発売日: 2013/11/20
- メディア: Kindle版
- この商品を含むブログ (3件) を見る
- DDDのパターンの中で、ファクトリは最も有名なもののひとつ
- ドメインモデルでファクトリを使えるようになるためのサンプルを示す
11.1 ドメインモデルにおけるファクトリ
- ファクトリを使う最大の動機
- 特定の型の集約をインスタンス化するだけで、他に責務がないオブジェクトはそのモデルの一級市民でない
- つまり、単純なファクトリクラスはドメインモデルではない
- 集約ルートが別の方の集約や別のパーツのインスタンスを作るファクトリメソッドを持つこともある
- この場合も集約ルートの責務は、集約の振る舞いを提供すること
- ファクトリメソッドは集約の振る舞いのひとつ
- 今回はこれがよく出てくる
- 集約の構造の重要な詳細は、間違った状態に変更されないためにも保護しておく必要がある
- 集約にファクトリメソッドを持たせる => コンストラクタのみでは表現できないユビキタス言語を表現できる
- 境界づけられたコンテキストの統合のときには、サービスがファクトリとして機能する
- アブストラクトファクトリ
11.2 集約ルート上のファクトリメソッド
- これまでの議論で出てきた、3つの境界づけら得れたコンテキスト内の、集約のルート上にある幾つかのファクトリ
CalendarEntryのインスタンスの作成
- CalendarのなかでCalendarEntryのインスタンスを作るためのもの
- テストコードは書籍参照
- テストコードでは識別子とインスタンスがそれぞれnullでないことをチェック
- ファクトリメソッドscheduleCalendarEntryの実装
- シナリオを検討した結果、CalendarEntryのpublicなコンストラクタだけではモデルの表現力が損なわれる
Discussionのインスタンスの作成
- Forumのユビキタス言語に沿ったファクトリメソッド、startDiscussion()
- 打ち合わせ開始という感じか
- Forum自体が閉じているときはDiscussionを作らないガード
- ファクトリメソッドは、コンテキストのユビキタス言語を表現
- ドメインエキスパートが言った内容そのままを表現できる
- シンプルであることがドメインモデラーの目指す道
11.3 ファクトリとしてのサービス
- 第13章で改めて議論する
- ここではファクトリそのものについてと、サービスをファクトリとして設計する方法について説明
- CollaboratorServiceの形式のファクトリ
- テナントとユーザの識別子を渡してCollaboratorのインスタンスを生成
- コラボレーションコンテキストのドメインにおける人を表す言葉、投稿者・作成者・モデレータ・所有者・参加者の生成
- 投稿者などは値オブジェクトとして扱う
- インターフェイスを定義、具象クラスで実装
- 実装はインフラストラクチャレイヤのモジュールに配置する
- 実装ではUserInRoleAdaptorでTenantとその識別子からAuthorクラスのインスタンスに変形する
- アダプターパターン
- 認証・アクセスコンテキストの公開ホストサービスとやり取りして、ユーザのロールがAuthorかチェック
- コラボレーションコンテキストではCollaboratorのidentity属性にusernameを使う
- インスタンスのライフサイクルと概念的な用語を2つの境界づけられたコンテキストから切り離すためにサービスベースのファクトリを利用した
