DDD 続き 173ページ。
問題領域を分析して作成したモデルを、利用シナリオでいつもチェックする必要がある。
モデルを確認していおく。貨物をルートとする、配送履歴と配送仕様を含む 集約(AGGREGATE) がモデルの中核。
配送履歴は ENTITY。
配送仕様は VALUE OBJECT。
サンプルのシナリオ1:配送先の変更
配送先は、配送仕様の属性。配送仕様は VALUE OBJECT だから、既存の配送仕様オブジェクトを捨てて、新しい配送仕様オブジェクトを set する。
String オブジェクトと同じ、不変オブジェクトである VALUE OBJECT の変更のやり方のお約束ですね。
配送先の変更は、このモデルでうまく扱えそう。
サンプルのシナリオ2:リピートの注文
同じ顧客は、似た注文をだすことが多い。たとえば、同じ配送先へ何度も送る。
だから、過去の貨物 ( AGGREGATE ) を取り出し、それを元に新しい貨物オブジェクトを作成する。プロトタイプパターンですね。
問題は、ENTITY のコピーは注意が必要。 ENTITY は、一意に識別して追跡するオブジェクト。だから、安易なコピーは、一意識別を破綻させる可能性がある。
貨物オブジェトが持つ属性とオブジェクトを検討する。
配送履歴
新しい、空のオブジェクトを作る。(配送履歴はコレクションなので、空のコレクションを作る)
ENTITY がAGGREGATE に含まれる場合のお約束ですね。
顧客ロール
顧客ロールは、送り手、受け手、請求先など、役割ごとに顧客と関係づける Map オブジェクト。
リピート注文は同じ顧客・ロールの組み合わせになることが多いので、 Map をコピー。
ただし、顧客オブジェクトはコピーしてはいけない。
そもそも、ロールは集約(AGGREGATE)の内側だけど、顧客は外側。だから Map は、顧客オブジェクトの実体ではなく、顧客への参照として実装すべき。
追跡番号
もちろん、新しい一意識別番号を発行する必要がある。
内部で済ませる
オブジェクトをコピーを作って、必要な変更を加える。すべて集約(AGGREGATE)の内部で済ませていることに注目。
集約の外部には、何も影響をあたえていない。リピートの注文は副作用のない操作として実装できる。
このモデルでうまく扱えそう。
---
Eric Evans は、利用シナリオを使って、モデルを頻繁にチェックすべきだと書いている。
でも、利用シナリオをどうやって用意するかとか、チェックのタイミングやレビュールールみたいな話はあまり書いていない。7章は、プロセス(やり方)の具体例としても興味深い。
この利用シナリオでモデルをチェックするというのは、
・ドメイン駆動で開発しているドメインモデル(クラス図)
・利用シナリオ(ユースケース)
・実装(コレクション、オブジェクト参照、DBアクセスなど)
の三つを突き合わせて一致させる作業。
こういう作業を頻繁に行うのがアジャイル開発の基本ですね。
開発者も、利用の視点、モデルの視点、実装の視点の三つの視点で多角的に議論できなきゃね。
問題領域を分析して作成したモデルを、利用シナリオでいつもチェックする必要がある。
モデルを確認していおく。貨物をルートとする、配送履歴と配送仕様を含む 集約(AGGREGATE) がモデルの中核。
配送履歴は ENTITY。
配送仕様は VALUE OBJECT。
サンプルのシナリオ1:配送先の変更
配送先は、配送仕様の属性。配送仕様は VALUE OBJECT だから、既存の配送仕様オブジェクトを捨てて、新しい配送仕様オブジェクトを set する。
String オブジェクトと同じ、不変オブジェクトである VALUE OBJECT の変更のやり方のお約束ですね。
配送先の変更は、このモデルでうまく扱えそう。
サンプルのシナリオ2:リピートの注文
同じ顧客は、似た注文をだすことが多い。たとえば、同じ配送先へ何度も送る。
だから、過去の貨物 ( AGGREGATE ) を取り出し、それを元に新しい貨物オブジェクトを作成する。プロトタイプパターンですね。
問題は、ENTITY のコピーは注意が必要。 ENTITY は、一意に識別して追跡するオブジェクト。だから、安易なコピーは、一意識別を破綻させる可能性がある。
貨物オブジェトが持つ属性とオブジェクトを検討する。
配送履歴
新しい、空のオブジェクトを作る。(配送履歴はコレクションなので、空のコレクションを作る)
ENTITY がAGGREGATE に含まれる場合のお約束ですね。
顧客ロール
顧客ロールは、送り手、受け手、請求先など、役割ごとに顧客と関係づける Map オブジェクト。
リピート注文は同じ顧客・ロールの組み合わせになることが多いので、 Map をコピー。
ただし、顧客オブジェクトはコピーしてはいけない。
そもそも、ロールは集約(AGGREGATE)の内側だけど、顧客は外側。だから Map は、顧客オブジェクトの実体ではなく、顧客への参照として実装すべき。
追跡番号
もちろん、新しい一意識別番号を発行する必要がある。
内部で済ませる
オブジェクトをコピーを作って、必要な変更を加える。すべて集約(AGGREGATE)の内部で済ませていることに注目。
集約の外部には、何も影響をあたえていない。リピートの注文は副作用のない操作として実装できる。
このモデルでうまく扱えそう。
---
Eric Evans は、利用シナリオを使って、モデルを頻繁にチェックすべきだと書いている。
でも、利用シナリオをどうやって用意するかとか、チェックのタイミングやレビュールールみたいな話はあまり書いていない。7章は、プロセス(やり方)の具体例としても興味深い。
この利用シナリオでモデルをチェックするというのは、
・ドメイン駆動で開発しているドメインモデル(クラス図)
・利用シナリオ(ユースケース)
・実装(コレクション、オブジェクト参照、DBアクセスなど)
の三つを突き合わせて一致させる作業。
こういう作業を頻繁に行うのがアジャイル開発の基本ですね。
開発者も、利用の視点、モデルの視点、実装の視点の三つの視点で多角的に議論できなきゃね。