web-dev-qa-db-ja.com

DDD-集計境界の重複を回避する方法は?

私は最近、DDDに関するEvanの本を読み始めました。私は、この本の原則のいくつかを、私が取り組んでいるプロジェクトの境界のあるコンテキストに適用してみることにしました。

関心のあるコンテキストは、アポイントメントとアポイントメントのスケジューリングを扱います。いくつかのビジネス要件と現在のモデルを紹介します。

私たちは従業員、予定、部屋を持っています。予約には、役割ごとに最大1人の従業員を含めることができます(たとえば、カウンセラー1人、医師1人)。これらの従業員は全員、予定の一部を別の時間に開始および終了します。たとえば、カウンセラーはx1からy1まで存在でき、医師はx2からy2まで存在できます(これらはオーバーラップするか、ばらばらになります)。予定は、最も早いxで始まり、最も遅いyで終わると見なされます。アポイントメントには、患者が1人しかいません。予約は部屋で行う必要があります。従業員は(自分の開始時間と終了時間に関して)重複する予定を持つことはできません。その部屋が別の予定で占められている場合、その部屋で予定を行うことはできません。

これは私が思いついたモデルです:

initial model

以前の不変条件に加えて、これらのビジネスルールを守る必要があります。患者は、一度に1つの予定のみを予約できます(予定にステータス属性があると想定します)。

モデルは次のユースケースをサポートする必要があります。

  • 予定のスケジュール。
  • 予約スケジュールの開始/終了時間の更新
  • 予定に別の従業員を割り当てる
  • 予定からの予定スケジュールの追加/削除

集計、そのルート、境界を定義するのに苦労します。与えられた制約から、DailySchedule集計がAvailabilityおよびAppointmentSchedule値オブジェクトを含む必要があることは明らかです。ただし、Appointmentには、AppointmentScheduleも含める必要があります。これは、アポイントメントごとに1つの従業員ロールのみが存在するという不変条件を維持するためです。さらに、部屋と患者は両方とも、それらの不変条件を維持するために予定を含む必要があります。

患者の不変条件をビジネスルール/ポリシーオブジェクトとしてモデル化できるとしますが、DailyScheduleとAppointmentは、その集計ルートを経由することなく、値オブジェクトへの参照を共有したままです。

このモデルでは、明確に定義された集計境界が許可されていないようです。私は、各ユースケースのサービスを公開することを検討していました。これは、集約境界にまたがり、そこからの不変条件を維持します。この問題に対する他の、おそらくよりエレガントでシンプルな解決策があるかどうか知りたいです。

5

あなたにとって良い出発点は、イブ・レインハウトの モデルの進化 です。ここで、彼はヘルスケアの予約のスケジューリングのモデリングについて説明しています。

倉庫システム に関するGreg Youngの議論を確認することもできます。要約は次のとおりです。データのスケジュールの競合を検出して報告するための合理的な方法がある場合、必ずしも違反の発生を防ぐ必要はないかもしれません。

これを理解するのに役立つ1つの洞察は、メッセージが到着する順序が正確性を保証するものではないということですレース条件が存在しない のUdi Dahanは観察します

タイミングのマイクロ秒の違いは、コアビジネスの動作に影響を与えません。

フランケンシュタイン博士は10:00から11:00までA室にいる必要があるというメッセージです。これは、彼女が10時30分から11時30分まで部屋Bにいる必要があることを示す別のメッセージです。 2つのメッセージに一貫性がないことは明らかですが、どちらが正しいのかはわかりません。特に、「間違った」予定をキャンセルするメッセージがすでに来ている可能性がありますが、まだ見ていません。

多くの場合、私たちが本当に探しているのは、Greg Youngが Stop Over Engineering ;で説明しているソリューションのようなものです。最初に問題を人間にエスカレートし、次にソリューションを自動化できるほど単純な問題を特定することに取り組みます。

衝突を防ぐために過度に制約するシステムは、多くの場合、ユーザーに失望する経験を与えます。データ入力エラーがありましたが、この予定のcorrectデータを入力する前に、システムはそのタスクを中断し、エラーの修正を要求します。さらに、そのエラーの修正は複雑になる場合があります。

スケジューリングシステムの役割は、競合を防止するのではなく、識別して解決することであることに留意すると、集計の設計方法に多くの自由があることに気付くでしょう。

4
VoiceOfUnreason