1

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

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

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

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

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

public class Location  // is an aggregate Root
{
    public IEnumerable<Field> Fields {get;set;} //in real code encapsulated. not here for brevity
}
public class Field  // is an Aggregate Root
{
    public Location Location {get;set;}  //reference to AR
    public IEnumerable<Task> Tasks {get;set;}
    public IEnumerable<Events> Events {get;set;}
}
public class Task // is an Aggregate Root
{
    public Field Field {get;set;}  // reference to AR
    public IEnumerable<Employee> Employees {get;set;}
    public TaskType TaskType {get;set;}  // probably Value Object
    public IEnumerable<Equipment> Equipment {get;set;}  // maybe Entity or AR
}

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

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

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

4

1 に答える 1

3

さて、もう少しグーグルすると、私はこの素晴らしいシリーズの記事を見つけました。

https://dddcommunity.org/wp-content/uploads/files/pdf_articles/Vernon_2011_1.pdf

パート2などに進むには、URLの最後のディジットを変更するだけです。

ここで、イヴが指摘しているように、私は骨材と骨材の根の目的を誤解していることを発見しました。それらは、相互に関係のある一連のエンティティを単に束ねるのではなく、関連するエンティティ間の一貫性を維持することを目的としていることがわかりました。

したがって、フィールドが特定の日に3つのタスクしか持てない場合、フィールドはARの候補として適しています。これは、タスクを追加するだけで、システムに無効な状態を簡単に作成できるためです。 Fieldのメソッドを介してタスクを追加すると、それが許容できるかどうかを簡単に確認できます。

さらに、巨大な集約ルートはロードに多くのリソースを必要とし、同時実行の問題を引き起こす可能性があるため、避けたいと考えています。などなど、上記の質問に対応する記事を美しく読んでください

于 2012-06-25T21:31:38.527 に答える