バスタイムテーブルによるDDDの例 - ドメインオブジェクトの特定

Question

私はDDDを実装しようとしていますが、エンティティ、値オブジェクト、および集合体のドメインオブジェクトの識別にはいくつか問題があります。私が現在取り組んでいる私のホームプロジェクトのデータベース構造は次のとおりです。

これらの表が意味するものをよりよく理解するための写真があります。

私はDDDの世界でこれらの表を参照してくださいどのようにされているとします。

私はこのことについて非常に強い疑問を持っています。それを見直して、何が間違っていると言うことができますか？

Answer 1

私はこれについて非常に強い疑念を抱いています。それを見直して、何が間違っていると言うことができますか？

あなたの図は、いくつかのエンティティを共有していると思われる複数の集約ルーツがあるという点で、非常に疑わしいです。これは、あなたがまだ集計境界の意味を理解していないことを示唆しています。

集約を正しく定義する重要な点は、モデルの状態をどのように変更できるかを理解することです。各集約は、境界内で発生する状態の変化に対して単独で責任を負います。集合体の外部にある論理は、集合体のルート実体を介してその状態にアクセスすることだけが許可される。

ウェイポイント集約と出発集計が両方とも責任を負うことを示唆している図は、ステーションが何か変わっていると示唆しています。

エンティティが集合体に属しているかどうかを判断しようとしている場合、もう1つの素早いヒューリスティックがあります。エンティティのライフサイクルは、その集合体のライフサイクル全体に収まるのでしょうか？そうでない場合、エンティティはその集合体の一部であってはならず、モデルを変更する必要があります。

この特定の例では、私はStationsがかなりのビットでWaypointsよりも長くなることを期待しています。これは、Stationへの変更は単一のWaypointの責任ではないことを強く意味します。

DDDの戦術的パターンは、実際にはオブジェクト指向開発のためのコード化されたプラクティスです。カプセル化と結束に注意を集中すると、境界がより明確になります。

Schedule-Routeの関係について何をお勧めしますか？ Routeを集計ルートにする必要があるので、スケジュールでそれを参照できますか？異なるたくさんのことを意味することができます

参考...私たちはスケジュールデータとルートデータを組み合わせてレポートを作成できるように

あなたは、スケジュールの状態でのルートエンティティの識別子を含むことができますか？絶対に。

スケジュールを介してルートエンティティの状態を変更することはできますか？ Routeのすべての変更は、Line集約によって検証する必要があります。

ルートエンティティの状態を使用して、スケジュールの変更を検証できますか？いいえ。ルートの状態は別の集計になっています。 Line集合体は、それを読み取ろうとしている間にそれを変更している可能性があります。

Routeエンティティの近似を使用して、スケジュールの変更を検証できますか？確かに - 通常の仕組みはドメインサービスをスケジュールに渡して、ルートの古いコピーを照会できるようにすることです。いくつかのデータ一貫性エラー（偽陽性と偽陰性の両方）がありますが、ドメインが特に変動しない場合、おそらくビジネスにとって大きな問題ではありません。