境界の定義と集約根の間の通信

Question

私のドメインモデルを少し理解し、私が正しくデザインに近づいていることを確認するためにいくつかの助けを使うことができます。

私は部署と呼ばれる集約根を持っています。部門オブジェクトには、「部署」のビジネス概念を定義するのに役立ついくつかの子価値タイプがあります。私のUIユーザーでは、部門オブジェクトを一覧表示、作成、編集、削除できます。

プロジェクトと呼ばれる別の集約ルートを持ちます。プロジェクトにはいくつかの子価値タイプがありますが、各プロジェクトが部門によって「所有」されているという点で部門との関係もあります。プロジェクトは作成、編集、削除されるなどを行うことができますが、部門への影響はありませんが、部署の削除はそれが所有するプロジェクトも削除します。

私のUIは、現在のユーザーがアクセスを許可されている部門に基づいてプロジェクトのリストを表示します。彼らは複数の部署にアクセスできるかもしれません。リスト項目の両方として表示されると、詳細だけでなく、プロジェクトで部門のロゴを表示する必要があります。

私の最初の考えは、プロジェクトは、部署を「ルックアップ」するために使用され得る単純なDepartmentIdプロパティを備えた集約根であった。しかし今、私は私が本当に1つの集約根だけを持っていると考えています：部門。

あなたはどう思いますか？

更新

議論の鍵であるかどうか、または何も変わったが、最初の2つの答えを読んだ後に次の考えが行われたかどうかわかりません。

部門は2つのコンテキストを持っているように見えます：

1. スタンドアロンエンティティとして 変更をサポートします。
2. プロジェクトの子として ケースには読み取り専用データが含まれています 行動なし。

   これは私のモデルに2つの「オブジェクト」を持つべきだと思います、ケース＃1の集約根とケース＃2の値タイプです。私は正しいトラックの上にいますか？

Answer 1

Since the Project can't exist without a Department it's probably not an Aggregate Root. From your description it sounds like you only have one AR - the Department, which you use to manage the projects inside it.

If your behavior is mostly CRUD, i would not recommend building a full blown domain model for it since there are probably simpler approaches you can take.

UPDATE As you mention, you might have 2 bounded contexts here. One where the Department is an AR and the Projects are entities of this AR. In this context you would perform operations on your Departments. In a second BC your Project could be the AR and the Departments could be entities or VOs. This would allow you to work directly with projects.

I would also recommend going over this with your domain expert and see if these concepts fit well in your UL, or maybe search for some missing concept that can clarify your model. I would especially look for a concept that might link projects to departments.

Answer 2

I think it's perfectly defensible to have both Project and Department be aggregate roots, since they are both managed independently.

That is, every Project and every Department have some kind of unique identifier, and while you can add Projects to Departments, Projects themselves are probably complicated enough (with their own lifecycles, their own child objects etc.) to warrant aggregate root status.

You just have to keep a reference to the Department in each Project.

Answer 3

Few simple questions to be answered:

1) can the department domain object live by its own without the Project domain object. - If yes, then the department is an aggregate.

2) Is the Project domain object can live by its own - If yes, then the Project is also an aggregate

3) Is Project has relationship with one Department - Then it should be part of the Project aggregate exposed as property Department

4) Is Department has relation ship with one or more Project objects - The the Project aggregate should be part of the Department aggregate object.

So, Using Department aggregate object you might need to access the list of Project(s) object and once you have the Project object you might need to access the Department object. It is a circular reference which is obsoletely fine.

It is a typical example of Employee has a manager and manager has a list of employees