問題タブ [aggregateroot]

http://i.stack.imgur.com/YZXZN.png（現在、画像を埋め込むことは許可されていません）

上記のクラスモデルで本当に助けを借りることができました。私は、大学でオブジェクト指向を学び、試験を書き、それに合格したが、実際のコードに原則を実装することに着手したことのない「それらの」開発者の1人であると言うのは恥ずかしいことです。成文化を始める前に、私は本当に座ってアプリケーションの設計を検討したことはありませんでした。したがって、私の設計とコーディングのスキルは、モノリシックなレガシーバンキングアプリケーションの開発と保守の重みの下でゆっくりと衰退し、停滞しています。これから何年も経った後、私は間違いなく変化の時だと判断しました！私はデザインパターン、DDD、NoSQL、DIなどの世界を深く掘り下げてきました。この2週間は、私にとって非常に激しい経験でした。また、大企業や銀行で働いていたときに見逃していた膨大な量のベストプラクティスや技術に涙を流しそうになったと思うこともあります。最先端のテクノロジーと優れたデザインアプローチからどれだけ離れていたのか、信じられませんでした。突然のすべてのスワスが、コーディング麻痺の状態に陥る恐れがありました。デザインをさらに微調整する必要がある、または特定のトピックについてさらに研究する必要があると感じたため、コーディングを開始できませんでした。ただし、十分です。プロジェクトをクラックして、少なくとも最初のイテレーションを行う必要があります。そして、すべての突然のスワスは、私をコーディング麻痺の状態に陥らせる恐れがありました！デザインをさらに微調整する必要がある、または特定のトピックについてさらに研究する必要があると感じたため、コーディングを開始できませんでした。ただし、十分です。プロジェクトをクラックして、少なくとも最初のイテレーションを行う必要があります。そして、すべての突然のスワスは、私をコーディング麻痺の状態に陥らせる恐れがありました！デザインをさらに微調整する必要がある、または特定のトピックについてさらに研究する必要があると感じたため、コーディングを開始できませんでした。ただし、十分です。プロジェクトをクラックして、少なくとも最初のイテレーションを行う必要があります。

とにかく、私の問題については、十分なドラマです：

ゴルフアプリのモデル作成に取り掛かりました。DDDにある程度準拠し、NoSQL（RavenDB）を利用したいので、次の要件に着手しました。

• 私のプラットフォームスタックはWindows/IIS / MVC 3.0/RavenDBです
• 骨材のルーツを見つける必要があります！私はそれらを、それ自体で存続することができる私のシステム内の唯一の要素として定義することに着手しました。他のすべては、単に集合体の「サブコンポーネント」と見なしました。実際の動作はまだ定義されていないことに注意してください。
• 私の集約ルートは、RavenDBドキュメントストアに実際に保持される唯一のクラスであり、「現状のまま」保持されます。大きなツリーのようなクラス構造を持つことは、実現されるパフォーマンス上の利点の観点から、RavenDBの最良のシナリオであるように思われます。
• RavenDB APIは流暢で非常に軽量であると感じているため、リポジトリレイヤーの必要性は感じていません（Ayendeの投稿の一部をフォローしています）。必要に応じて、コントローラーのカスタムアクション属性を使用してセッションを開いたり閉じたりするだけです。リポジトリレイヤーなしでテストするのは難しいかもしれませんが、確かにいくつかの「メモリ内」ドメインオブジェクトをモックすることができるはずです。
• DBへの書き込みは、別のサービスレイヤーで行われます。
• ある時点で私は立ち止まり、「いったいどこに自分のドメインの振る舞いを置くつもりなのか！？」と自問しました。Webの検索から得られた一般的なコンセンサスは、ドメイン（エンティティ）に動作（ビジネスロジック）を持たせず、すべてをサービスレイヤーで処理する必要があることを示しているようです。しかし、Eric Evansをいくつか読んだ後、私のドメインの動作の多くがそこに存在するはずだと確信しています...ドメイン内に！

質問 -DDDと建築設計の分野における善意の初心者として、私は少なくとも正しい方向に進んでいますか、それとも破壊される運命にありますか？-上記に対する考え、警告、建設的な批判、洞察をいただければ幸いです。

かなり複雑なシナリオを処理するための最良の方法を見つけるのに少し苦労しています。私はかなりの数の同様の質問を見てきましたが、満足のいくようにこのシナリオに対処したものはありませんでした。

Order（集約ルート）は、複数のOrderLine（子エンティティ）で作成されます。ビジネスルールに従って、各OrderLineは、注文の存続期間中、同じIDを維持する必要があります。OrderLineには多くの（20以上の）プロパティがあり、Orderが「ロックされている」と見なされる前にかなり頻繁に変更できます。さらに、ルートレベルで適用する必要のある不変条件があります。たとえば、各注文明細には数量があり、注文の合計数量はXを超えることはできません。

OrderLinesの変更を検討する際に、このシナリオをモデル化する方法がわかりません。私には4つの選択肢がありますが、どれも満足のいくものではないようです。

1）OrderLineを変更するときは、ルートから提供された参照を使用して変更します。しかし、ルートの不変ロジックをチェックする機能が失われます。

2）注文のメソッドを呼び出します。すべての不変ロジックを適用できますが、OrderLineの多くのプロパティを変更するためのメソッドの急増に悩まされています。

3）OrderLineを値オブジェクトとして扱った方が簡単かもしれませんが、ビジネス要件ごとに同じIDを維持する必要があります。

4）不変条件に影響を与えない変更については、OrderLinesへの参照を取得し、影響を与える変更についてはOrderを調べることができます。しかし、不変条件がほとんどのOrderLineプロパティの影響を受ける場合はどうなるでしょうか。不変条件に影響を与える可能性のあるプロパティはごくわずかであるため、この異論は仮説ですが、ビジネスロジックが明らかになるにつれて、状況は変化する可能性があります。

任意の提案をいただければ幸いです...私が密集している場合は、遠慮なくお知らせください。

簡単なことを見落としていることはほぼ間違いありませんが、クリックされていません。

Personエンティティ（Person集計のルート）があります。また、ロールのリストと権限のリストを持つ認証と承認（Auth）の子エンティティがあります。

ルートでAddAuthRoleなどのメソッドを使用して、ルートを介してロールと権限の変更を管理したい。

これはかなり簡単ですが、Authエンティティで同様の機能を公開せずにこれを行うにはどうすればよいですか？子への参照を使用しているコンシューマーが、これらのリストに対して追加と削除を試みてほしくない。

これは基本的なOOの概念であり、気づかないことを恥じるべきだと感じています...

次の DDD とリポジトリ パターンを使用して、遅延読み込みを使用する代わりに、子データが既に含まれている集約ルート オブジェクトを返すことは可能ですか?

たとえば、集約ルートとして倉庫エンティティがあり、それには location という子オブジェクトがあります。

リポジトリには、ロケーション ID を照会する以下のメソッドがありますが、倉庫エンティティを返します。

Warehouse.location を使用すると、EF はプロキシ クラスを使用して別の DB クエリを起動し、位置データを取得します。私のリポジトリ メソッド FindByLocationId で、場所 DB テーブルをクエリし、場所データを含む倉庫エンティティを返すことはできますか?

イベントソーシングを使用して、イベントのストリームから集計を構築しています。A1 と A2 の 2 つの集計があります。A1 は、A2 を作成するためのテンプレートとして使用されます。A1のサイズはかなり大きいです。イベント ソーシングの基本的な考え方は、アプリケーションの状態に対するすべての変更がイベント オブジェクトに確実に取り込まれるようにすることです。したがって、A2 を保存するには、最初のイベントに多くの情報を保存する必要があります。

この状況は一般的ですか、それともテンプレートから作成するのは良い考えではありませんか? それを解決するためのより良い方法はありますか？

Aggregatesについて Entity Framework にどのように伝えることができますか?

1. 集計を保存するときは、集計内のエンティティを保存します
2. 集計を削除するときは、集計内のエンティティを削除します
3. 2 人の異なるユーザーが同じ集計内の 2 つの異なるエンティティを変更しようとすると、同時実行エラーが発生します
4. 集計をロードするときは、集計内のすべてのエンティティにアクセスする前に多少の遅延がある場合でも、集計の一貫したポイント イン タイム ビューを提供します。

(Entity Framework 4.3.1 Code First)

ビデオ デマンド システムの一部であるアーカイブをモデル化しています。複数のユーザーがフォルダーの作成、ビデオのアップロード、フォルダーの再構築などを行うことができる Windows エクスプローラーのようなアーカイブを考えてみてください。ユーザーがタスク (フォルダーの名前変更、フォルダーの移動、フォルダーの表示など) を実行できるかどうかを決定するビジネス ルール (アクセス許可) があります。 ）。

各フォルダーを集約ルートとしてモデル化し、あるフォルダーを別のフォルダーに移動すると、2 つの集約ルートに影響するように見えます。

私が理解していることから、イベントを送信して他の集計を変更する必要があります。ただし、2 番目のフォルダーも変更された場合 (システムから削除または削除された場合など)、最初の集計の変更を元に戻すには、補正コマンドを送信する必要があります。

移動 (両方の集計での変更) を一緒に処理するある種のトランザクションを好みます。それが失敗した場合、少なくとも移動の最初の部分を元に戻したり、イベントの最初の部分を発生させたりする必要はありません。

これにより、CQRSは私が解決しようとしている問題に適していますか? もしそうなら、私の集計が間違っている可能性がありますか?

このような質問が無数にあることを私は知っています。ごめんなさい。私のは違うと思いますが、そうではないかもしれません。私はDDDを初めて使用し、把握しようとしています。私のドメインの一部はこのようなものです。場所 1-* フィールド フィールド 1-* イベント フィールド 1-* タスク タスク-従業員

AR が場所のように見えます。そして、特定のタスクを取得したい場合は、フィールドのコレクションからタスクのコレクションまで、そのタスクまでたどる必要があります。

私はタスクやイベントを頻繁に扱っており、言うまでもなく場所を指定することはほとんどないため、これはかなり面倒に思えます。場所は、フィールドのグループとそれに対応するエンティティを分離するのに役立ちます。そのため、UI では、場所を選択してフィールドのリストを取得できます。次に、フィールドを選択します。そこから、そのタスクの 1 つを編集できます。タスクのコレクションがあり、そのうちの 1 つを選択して、タスクの ID を取得します。次に、AR を取得してタスクに戻ることができるように、その場所までトラバースして彼の ID を取得する必要があります。というか、取得できるように AR の ID を保持しておきます。では、フィールドの ID も維持する必要がありますか? サーバーに返すのは、見たい AR.Id、Field.Id、および Task.Id でしょうか?

第二に、従業員はもちろんエンティティになることはできず、AR である可能性が最も高いです。AR 上のエンティティが AR のコレクションを持つことは問題ありませんか?

では、このような構造にするべきではないでしょうか。

これにより、最も変更されたオブジェクトを処理し、それらの関係をトラバースすることがはるかに簡単になりますが、昔ながらの OOP のように感じられ、AR は実際には何の意味もありません。

繰り返しますが、私は DDD を初めて使用し、健全性チェックのためにこれを実行する人がいません。これらの境界がどのように描かれるかを理解するのを手伝ってください。それが最初の方法である場合、エンティティを処理し、AR.id、ParentParent.Id、ParentId、そして最後にのオブジェクトを持ち運ぶ簡単な方法はありますか?興味 Entity.Id

ご意見ありがとうございます R

私はこのデザインを持っています：

製品には多くの価格設定グリッドがあり、グリッドには多くの価格設定期間があります

今、私は特別オファーを持っています。売り手がオファーを作成するとき（たとえば、-10％）、それを製品に適用するか、グリッドに適用するかを選択できます（たとえば、グリッドにオファーを適用したくない場合）。 .apartnerwebsite.com "ですが、彼はそれをグリッド" my website "）に適用することを好みます。

ただし、グリッドIDがなく、ルートアグリゲートからリーフを参照できないため、これを行うことはできません。

集約ルートはクライアントによってロードされる唯一のオブジェクトであり、集約ルート内のオブジェクトに対するすべての操作は集約ルートによって行われることを理解しています。同じ規則により、集約ルートに対して定義された 1 つのリポジトリ インターフェイスが存在し、集約ルート内の任意のオブジェクトの永続化操作は、集約ルートに対応するこの「集約ルート リポジトリ」によって実行される必要があります。これは、集約ルートのサブオブジェクトに関連する操作のために、集約ルートオブジェクトのみを「集約ルートリポジトリ」に渡す必要があることを意味しますか?

例を挙げましょう。

School オブジェクトと Student オブジェクトがあるとします。Student は School なしでは存在できないため (学生は学校を辞めた可能性があると言うかもしれません。この場合、彼/彼女はもはや学生ではありません)、次のようになります。

ここでは School が集約ルートです。ここで、永続化操作用のリポジトリを定義するとします。

次のうち正しいものはどれですか?

1)

2)

1) では、インターフェースで集約のみを公開しています。したがって、ISchoolRepository を実装する DAL は、学生を追加するために School オブジェクトから Student オブジェクトを取得する必要があります。2) はより明白に見え、1) を提案することで私は愚かに見えるかもしれませんが、純粋な理論における総根の概念は 1) を示唆します。