帮助确定聚合根
我陷入了分析瘫痪的漩涡,试图将 DDD 应用于各种 我过去开发过或计划将来开发的应用程序。
让我们以一个简单的垒球联赛为例。我们有联赛、球队 属于一个联盟(只有一个),以及属于单个球队的球员。我知道 这些规则可能会有所不同,但我们假设一下。
在我看来,如果你删除一个联赛,一支球队就无法存在 联赛你删除了属于它的所有球队(以及球员),所以我有 这里的一个聚合,根是联赛。现在团队也很重要 概念,那么这是否意味着团队也可以是自己的聚合根?埃文斯 指出当您删除聚合根时,其所有内部也会删除, 所以这将使一支球队没有母联赛。
如果有人能阐明一些观点,我将非常感激。
谢谢
I am stuck in a vortex of analysis paralysis trying to apply DDD to various
applications i have either developed in the past or plan on doing in the future.
Lets take for example a simple softball league. We have leagues, teams that
belong to a league (just one), and players that belong to a single team. i know
these rules can vary, but lets just pretend.
the way I see this is a team cannot exist without a league and if you delete a
league you delete all the teams belonging to it (as well as players), so i have
one aggregate here with the root being league. now teams are also an important
concept, so does that mean a team could also be its own aggregate root? evans
states that when you delete an aggregate root, all its internals delete as well,
so this would leave a team without a parent league.
if someone could shed some light i would be very grateful.
thanks
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
您至少问过非常类似的问题三个 次。领域始终相同:运动队、联赛和球员,但您提供的详细信息始终不同,这就是您获得并接受不同答案的原因。你显然处于分析瘫痪的状态。您第一次就想出完美模型的可能性很小。开始编写代码和测试,您将立即得到反馈。寻找代码异味,重构,更好的模型将会出现。
关于这个版本的问题。聚合定义:
典型的例子是订单作为聚合根,订单行作为实体,它们是订单聚合的一部分。请注意,订单行在订单之外没有任何意义。
在你的情况下,“没有联盟就无法存在球队”的规则是不同的。仅仅宣布团队成为联盟聚合的一部分是不够的。它类似于“没有客户就无法存在订单”。这并不意味着客户是订单聚合的一部分。客户是它自己的聚合体,它本身就有意义。就像团队本身有意义一样,它有自己的历史、粉丝等。
这个问题也可以从“数据交换”的角度来解决。在埃文的例子中,整个订单被锁定,以便可以强制执行内部不变量。如果您对联赛进行更改,您是否还希望所有球队和球员也被锁定?
因此,根据您这次提供的信息,您需要两个聚合:联盟和团队。请记住,聚合可以相互引用。
You've asked very similar question at least three times. The domain is always the same: sport teams, leagues and players but the details you provide are always different and this is why you get and accept different answers. You clearly in the state of analysis paralysis. There is very little chance that you would come up with the perfect model the first time. Start writing code and tests and you will get immediate feedback. Look for code smells, refactor and a better model will emerge.
Regarding this version of the question. Aggregate definition:
And the classic example is Order as Aggregate root and Order Lines as Entities that are part of the Order Aggregate. Note that Order Lines do not make sense outside of the Order.
In your case the rule that "team cannot exist without a league" is different. It is not enough to proclaim Team to be a part of League Aggregate. It is similar to "Order can not exist without a Customer". It does not mean that the Customer is part of the Order Aggregate. Customer is its own Aggregate, it makes sense on its own. Just like the Team makes sense on its own, it has its own history, fans etc.
This problem can also be approached from 'data-exchange' stand point. In Evan's example the whole Order gets locked so that internal invariants can be enforced. If you make changes to the League would you also want all Teams and Players to be locked as well?
So based on the information you provided this time you need two Aggregates: League and Team. Keep in mind that Aggregates can reference each other.