聚合根取决于用例，这是否意味着我们最终可能会拥有很多存储库？
我听说很多聚合根取决于用例。但这在编码环境中意味着什么？
您有一个服务类，它当然包含将在存储库中完成某些操作的方法（用例）。太好了，因此您可以使用相当于聚合根的存储库来执行查询。
现在您需要执行一些其他类型的操作，这些操作使用与第一个服务类完全不同的用例，但使用相同的实体。
这里的表示：
实体：客户、订单、LineOrder
服务 1：添加新客户、删除一些客户、检索客户订单
这里的聚合根似乎是客户，因为您需要此存储库来执行这些用例。
服务 2：从实际订单中检索客户
这里的聚合根似乎是 Order，因为您需要此存储库来执行此用例。
如果我错了请纠正我。现在这意味着你有 2 个聚合根。
现在我的问题是，由于聚合根取决于用例，这是否意味着如果您最终有很多用例，我们最终可能会得到很多存储库？
上面的示例可能不是最好的例子...假设我们有一个日记本，其中包含日记条目，每个条目都包含任务、问题和注释。 （这是在告诉系统对项目做了什么的背景下）
这是否意味着我最终会得到 2 个存储库？ （期刊、期刊条目） 在我需要从日记条目中添加新任务、问题和注释的用例中？ （可以看作是一个服务）
或者最终可能会得到 4 个存储库。 （日志、任务、问题、笔记） 在我需要访问指导任务、问题和注释的用例中？ （可以看作是另一个服务）
但这意味着如果我需要这两个服务（实际上保存用例），我实际上需要 5 个存储库才能在这两个服务中执行用例？
Ive heard a lots that aggregate roots depend on the use case. But what does that mean in coding context ?
You have a service class which offcourse hold methods (use cases) that gonna accomplish something in a repository. Great, so you use a repository which is equal to an aggregate root to perform your querying.
Now you need to perform some other kind of operation which use totally different use case than the first service class but use the same entities.
Here the representation :
Entities: Customer, Orders, LineOrder
Service 1: Add new customers, Delete some customers, retrieve customer orders
Here the aggregate root seem to be Customer because you need this repository to perform thoses use cases.
Service 2: Retrieve customer from an actual order
Here the aggregate root seem to be Order because you need this repository to perform this use case.
If i am wrong please correct me. Now that mean you have 2 aggregates roots.
Now my question is, since aggregate roots depend on the use case does that mean that we might end up with really a lots of repositories if you end up having lots of use cases ?
The above example was probably not the best example... so lets say we have a Journal which hold JournalEntries which each entries hold Tasks, Problems and Notes. (This is in the context of telling to a system what have been done to a project)
Does that mean that im gonna end up with 2 repository ? (Journal, JournalEntry)
In the use cases where i need to add new tasks, problems and notes from an journal entry ?
(Can be seen as a service)
Or might end up with 4 repository. (Journal, Task, Problems, Notes)
In the use cases where i need to access directment task, problems and notes ?
(Can be seen as another service)
But that would mean if i need both of theses services (that actually hold the use cases) that i actually need 5 repository to be able to perform use cases in both of them ?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
你好，我看到了你的帖子，我想我可以给你我的意见。首先我必须说我已经在项目中进行 DDD 三年了，所以我不是专家。但我目前正在一个项目中工作，担任 DDD 领域的架构师和开发人员辅导，我必须说这不是在公园散步......我不知道我重构了多少次模型和实体关系。
但我的经验是，你最终会得到一些存储库（不少于但不多）。我的聚合通常包含一些类，并且聚合对象图并不那么深（如果您知道我的意思）。
但我尝试具体一点：
1）聚合根是根据您的需求定义的。我的意思是，如果您觉得您经常需要通过 Journal 来使用 Tasks 对象，那么也许这就是将其升级为聚合根的标志。
2）但不可能所有东西都是聚合根，所以尽量封装紧密相关的对象。 Notes 似乎是由根对象拥有的候选者。您可能总是将注释与根相关联，否则它会失去其上下文。笔记不能独立存在。
3）请记住，聚合用于将大型复杂域分割成较小的“岛屿”，以照顾其居民。重要的是不要让您的域变得比实际更复杂。
4) 在进入项目实施阶段之前，您并不知道您的模型是什么样子。如果您意识到某些存储库使用得不多，它们可能是合并到其他根对象的候选者（如果它们具有这种关系）。您可以通过根对象来分解经常使用的对象，而无需其上下文。我的意思是，例如，如果日记是聚合根并包含注释和任务。一段时间后，你的模型会增长，也许任务会增长
与 Action 和 ActionHistory 以及 User 和 Rule 和 Permission 具有关联。现在我只是在规则/操作/用户权限功能中抛出一堆常见对象。也许这会导致从另一个角度处理任务的用例，“查看该用户执行的所有任务”等。任务更多地参与某种状态/工作流引擎，因此成为聚合根本身的候选者。
好的。这不是最好的例子，但它可能会给你启发。根对象可以包含子对象，其中一些子对象也可以是根对象，因为我们在另一个上下文（而不是日志）中需要它。
但每次你用一个新模型启动时，我都会把头撞到墙上。只需顺其自然，让模型通过其客户/订阅者自行发展。您可以通过使用模型来完善模型。服务（应用程序服务而不是域服务）当然可以通过响应 UI 和用例（通常是一对一）的方法进行扩展。
我希望我能以某种方式帮助你......或者没有：D
Hi I saw your post and thought I may give you my opion. First I must say I've been doing DDD in project for three years now, so I'm not an expert. But I'm currently working in a project as an architect an coaching developers in DDD, and I must say it isn't a walk in the park... I don't know how many times I've refactored the model and Entity relationships.
But my experience is that you endup with some repositories (more than few but not many). My Aggregates usually contains a few classes and the Aggregate object graph isn't that deep (if you know what I mean).
But I try to be concrete:
1) Aggregate roots are defined by your needs. I mean if you feel that you need that Tasks object through Journal to often, then maybe thats a sign for it to be upgraded as a aggregate root.
2) But everything cannot be aggregate roots, so try to capsulate object that are tight related. Notes seems like a candidate for being own by a root object. You'd probably always relate Notes to the root or it loses its context. Notes cannot live by itself.
3) Remember that Aggregates are used for splitting up large complex domains into smaller "islands" that take care of thier inhabbitants. Its important to not make your domain more complex than it is.
4) You don't know how your model look likes before you've reached far into the project implementation phase. If you realize that some repositories aren't used that much, they may be candidates for merging into other root object (if they have that kind of relationship). You can break out objects that are used so much through root object without its context. I mean for example if Journal are aggregate root and contains Notes and Tasks. After a while you model grows and maybe Tasks
have assoications to Action and ActionHistory and User and Rule and Permission. Now I just throw out a bunch om common objects in a rule/action/user permission functionality. Maybe this result in usecases that approach Tasks from another angle, "View all Tasks performed by this User" etc. Tasks get more involved in some kind of State/Workflow engine and therefor candidates for being an aggregate root itself.
Okey. Not the best example but it maybe gives you the idea. A root object can contain children where some of its children can also be root object because we need it in another context (than journal).
But I have myself banged my head against the wall everytime you startup with a fresh model. Just go with the flow and let the model evolve itself through its clients/subsribers. You refine the model through its usage. The Services (application services and not domain services) are of course extended with methods that respond to UI and usecases (often one-to-one).
I hope I helped you in someway...or not :D
是的，您很可能最终会得到 5 个存储库（Journal、JournalEntry、Task、Problems、Notes）。然后，您的服务将使用这些存储库为每种类型的实体执行 CRUD。
对于刚接触 DDD 的开发人员来说，您的“哇这么多存储库”的反应并不罕见。
然而，假设您的模型和数据库模式相当均匀地匹配（通常是这种情况），您的存储库通常是轻量级的。如果您使用 ORM（例如 nHibernate）或工具（例如 Codesmith 生成器），那么创建存储库会变得更加容易。
Yes, you would most likely end up with 5 repositories (Journal, JournalEntry, Task, Problems, Notes). Your services would then use these repositories to perform CRUD for each type of entity.
Your reaction of "wow so many repositories" is not uncommon for developers new to DDD.
However, your repositories are usually light weight assuming your model and DB schema are fairly evenly matched which is often the case. If you use an ORM such as nHibernate or a tool such as codesmith generator then it gets even easier to create your repositories.
首先，您需要定义什么是聚合。我不知道用例聚合。
我知道以下聚合...
聚合是多个实体的联合。其中一个实体是聚合根，其余实体（或值类型）仅在选定的聚合根上下文中有意义。
例如，如果您不需要对 OrderLine 实体执行任何独立操作，则可以将 Order 和 OrderLine 定义为聚合。这意味着 OrderLine 仅在 Order 上下文中才有意义。
为什么要定义聚合？需要减少对象之间的引用。这将简化您的域模型。
当然，如果 OrderLine 是 Order 聚合的一部分，则不需要 OrderLineRepository。
这是链接 提供更多信息。你可以阅读 Eric Evans DDD 的书。他很好地解释了聚合。
At first you need to define what is aggregate. I don't know about use case aggregates.
I know about aggregates following...
Aggregates are union of several entities. One of the entities is the aggregate root, the rest entities (or value types) have sense only in selected aggregate root context.
For example you can define Order and OrderLine as an aggregate if you don't need to do any independent actions with OrderLine entities. It means that OrderLine makes sense in Order context only.
Why to define aggregates at all? It is required to reduce references between objects. That will simplify you domain model.
And of course you don't need to have OrderLineRepository if OrderLine is a part of Order aggregate.
Here is a link with more information. You can read Eric Evans DDD book. He explains aggregates very well.