問題タブ [aggregateroot]

ドメインモデルを設計していますが、うまくいかないことがあります。

私は主な骨材から始めます。他のアグリゲートへの参照があり、それらの他のアグリゲートはより多くのアグリゲートも参照します。メインアグリゲートから開始して、ホールドメインモデルを移動できます。

私が目にする問題は、アグリゲートのすべてのインスタンスをメモリに保持することです。

それは良いデザインですか？遅延読み込みでメモリの問題を解決することはできますが、もっと深刻な問題があると思います。

集約参照に関して別の質問があります。他のアグリゲートへの参照を遅延ロードする必要がありますか？その場合、私は彼らのリポジトリを使用することはほとんどありません。それは大丈夫ですか？

以下のような AR を設計した場合、オーダー ライン オブジェクトの 1 つでプロパティを更新するにはどうすればよいと思いますか?

たとえば、注文明細のタイトルを変更するにはどうすればよいですか (質問例)

これは注文集約ルートです

エンティティのリストを持つCity集計があります。PointOfInterestこの後者のエンティティは、ここでは説明しない理由により、City 集計内に論理的に存在します。集約ルートである City を除いて、PointOfInterest へのリンクを保持するエンティティはありません。

idただし、(主に SEO の理由で) その URLに PointOfInterest しかない、City ページから参照できる PointOfInterest の Web ページがあります。

したがって、コントローラーから、CityRepository に PointOfInterest などを直接クエリすると便利CityRepository.findPointOfInterestById()です。

もう 1 つのオプションは、 を照会してから を実行することCityRepository.findCityByPointOfInterestId()ですCity.findPointOfInterestById()が、この場合は少し面倒に見えます。

最初のアプローチに何か問題がありますか？

私は会議オブジェクトを持っています:

Meeting{id, name, time, CreatedBy, UpdatedBy}

そして

MeetingAssignee{id, MeetingID, EmployeeId, CreatedBy, UpdatedBy)

Meeting は Aggregate ルートとして、メソッド AssignEmployee を持っています。

AssignEmployee を呼び出すときに現在のユーザーを Meeting オブジェクトに渡そうとしていたので、それに応じて監査フィールドを更新できます。

しかし、これは正しくないようです。明らかに、監査フィールドを公開しておき、後で変更することができます-おそらくサービスレベルで?

これらのフィールドを更新するために誰もが好む他の方法は何ですか?

注: 私たちは Nhibernate を使用していませんが、自動化されていないカスタム ORM を使用しています。

ありがとう。

私は最初の単純なアプリケーション DDD スタイルを設計し始めており、概念がどのように連携するかを理解し始めています。

従来のブログ アプリケーションを設計する場合、Article クラスは集計ルートの 1 つになります。記事を取得し、関連するすべてのデータ (発行日、著者など) を管理および削除したい。コメントに困っています。最初は、コメントは Article 集合体の一部であるエンティティのように見えます: コメントは記事に関連して作成されます。記事を削除すると、関連するコメントも削除されます。

次に、任意の記事について、ブログに投稿された最新のコメントを含む小さなボックスをブログに表示したいと考えています。したがって、データ ストアからコメント (およびコメントのみ) を取得したいようです。DDD のアイデアに対する私の理解からすると、それは集約ルートになります。しかし、コメントはアーティクルに強く依存しているように見えるので、それは完全に正しいとは思えません。

どのようにモデル化しますか？

ありがとう。

Customer2 つの集約ルートとOrder「共有」エンティティで構成されるモデルのシナリオを考えてみましょうAddress。

また、 には次のサブクラスがあるAddressことに注意してください: 、および。abstractPhysicalAddressPostOfficeBoxAddressPrivateBagAddress

Customerは、ある種のアドレス帳に整理された多数のアドレスを持つことができます。注文時に、顧客はAddressアドレス帳から配送先住所として使用する を選択します。

最初は 2 つのエンティティ間でアドレスを共有することを考えていましたが、それぞれの不変条件の管理に問題が生じるため、オプトアウトしました。

もう 1 つの選択肢として、 の 2 つの階層を作成しAddress、それぞれを顧客の住所または配送先住所として使用する方法があります。繰り返しコードがたくさんあるので、これも正しくないようです。

この状況を適切にモデル化するにはどうすればよいでしょうか?

WorkItemドメインモデルの一部として、オブジェクトがあるとしましょう。オブジェクトには、次のWorkItemようなルックアップ値との関係がいくつかあります。

WorkItemType：

• UserStory
• バグ
• 強化

Priority：

• 高い
• 中くらい
• 低い

Statusそして、、、などのように、おそらくもっとあるかもしれませんSeverity...

DDDは、アグリゲートルート内に何かが存在する場合、アグリゲートルートの外部でアクセスを試みるべきではないと述べています。したがって、Taskなどの新しいWorkItemTypesやCriticalなどの新しいPrioritiesを追加できるようにする場合、これらのルックアップ値は独自のリポジトリを持つ集約ルートである必要がありますか？これは、特にキーと値のペアにすぎない場合は、少しやり過ぎのようです。ユーザーがこれらの値を変更し、集約ルートカプセル化ルールに準拠できるようにするにはどうすればよいですか？

私は DDD にかなり慣れていないので、実用的な観点から集計の優れた関数を探しています。ユーザー ( User) の長いリストがあり、そのための集計 ( UserAggregate) を作成します。

私の見解では、さまざまな基準に基づいてユーザーを表示する可能性があります。ここで、データベース クエリでリストを並べ替えないと仮定しましょう。集計で並べ替えを行っても問題ないでしょうか。これを適切に実行できるアプリケーションの別の部分を思いつくことはできませんが、集計の機能を誤解している可能性があります。

ちなみに、フィルタリングについても同じことが言えます。DDD 集計について読んだとき、すぐにDoctrine\Common\Collections\Collection(リンク) を思いつきました。そのようなものは、私には集合体のように見えます。だからDDDの専門家は、私を啓発してください:-)

アップデート

ところで、私が考えていた唯一の方法は、集計をかなり不平等にし、新しい集計を作成するヘルパーを用意することでした。しかし、これは進むべき道ではないようです：

2 番目の集計は新しいインスタンスであるため、ヘルパーは次のようになります。

2 つの集約ルートと 2 つの非集約ルート エンティティがあります。

私は、関係がD -> BDDDの原則に違反していることを知っています。

ほとんどの場合、解決策は参照されたエンティティを新しい集約ルートにすることだと聞きました。

しかし、 B が A の本当の子である場合(B は A なしでは生きられない) 、B を新しい集約ルートにするオプションは本当にあるのでしょうか?

私はすでに答えを知っているのではないかと思いますが、誰かがこれまでに見つけられなかった代替の解決策を提供できることを望んでいます。いつものように、効果的な骨材設計に従ってDDDを実行することは、私が思っていたよりも難しいですが、これが私のシナリオです。

• UserとRoleGroupの2つのARがあります
• ユーザーには特定のRoleGroupを付与できるため、そのロールグループ内のRoles（コレクション値オブジェクト）によって提供されるアクセス許可を取得できます。ロールグループのIDは、別のVAとしてユーザーARに保持されます。
• RoleGroupがシステムから削除されると、ハンドラーがそのRoleGroupを参照しているすべてのユーザーを検索し、参照を削除するために使用するドメインイベントが発生します。対応するプロジェクションデノーマライザーは、同じイベントを使用して、ユーザーの有効な役割を更新します。これは、そのユーザーに付与された個々のロールと、付与されたすべてのロールグループのロールの組み合わせです。
• これはトランザクションである必要はありません（結果整合性が得られるようになりました）。
• JonathanOliverのEventStore3.0と、Lokad.CQRSおよびNCQRSの要素を使用したイベントソーシングを使用します。

したがって、理論的には、1つの要求（ASP.NET MVCアプリ）が上記のシナリオを実行しているときに、別の要求が同じRoleGroupをユーザーに付与している可能性があります。上記のドメインイベントハンドラーがそのRoleGroupに関連するユーザーをスキャンした直後にそれが発生した場合、その要求は完了します。その時点で、（物理的ではありませんが）削除されたRoleGroupと、そのRoleGroupのIDを保持しているユーザーがいます。

これをどのように防ぎますか？現在、RoleGroup ARの特定のRoleGroup部分を付与されたユーザーのIDを作成することを検討しています。これにより、RoleGroupを削除してユーザーに付与すると、楽観的同時実行性の競合が発生します。しかし、どういうわけか、これは正しい解決策のようには感じられません。