领域驱动设计 - 聚合根设计问题
我目前正在重构一个系统。
我遇到以下情况：
该系统旨在提供有关跨多个业务部门的公司的信息。 每家公司都可以活跃于一个或多个领域。公司可以参加某些合作伙伴计划。一家公司可以拥有一个或多个合作制造商（例如，车库可以与宝马/梅赛德斯建立合作伙伴关系）等。所有这些参与都存在一定的时间段（有效期）。此外，像宝马这样的制造商必然局限于某一业务领域。因此，只有宝马对公司业务部门有效的情况下，公司才能成为宝马的合作伙伴。也就是说，因为该系统不仅维护像车库这样的商业部门的公司，而且还维护拖车服务等。
所以现在我的设计可能会导致一些不变量。
公司->作业（不会慢慢变化）->业务部门
公司 ->合作伙伴关系（日期从 - 到）->组织 <- 业务部门
公司和组织必须共享相同的业务部门分配。
因此，现在，人们可以改变组织的业务部门分配。那么这个同业部门的规则就失效了。
你会如何建模这样的东西？
I am currently refactoring a system.
I've got the following situation:
The system is about providing information about companies across several business sectors.
Each company can be active in one or more sectors. Companies can be participating in certain partner programmes. An a company can have one or more partner manufacturers (e.g. a garage can have a partnership with BMW/Mercedes) etc. All of these participations exist a given period of time (validity period). Additionally, a manufacturer like BMW is bound to one business sector. So a company can only be partner of BMW, if BMW is valid for the companies business sector. That is, because the system does not just maintain companies of a business sector like a garages, but also towing services etc.
So right now my design can cause some invariants.
Company -> Assignment (not slowly changing) -> Business Sector
Company -> Partnership (date from - to) -> Organisation <- Business Sector
Where Company and Organisation must share the same Business Sector assignment.
So right now, one could change the business sector assigment of an Organisation. Then this would the rule of having the same business sector to be invalid.
How would you model something like that?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
我看到了执行此业务规则的 2 种符合 DDD 的方法：
DDD 指定聚合中的不变量应由聚合根强制执行。如果公司是您的聚合根，当您向其中添加新的合作伙伴关系时，它可以检查该合作伙伴关系是否符合商业部门规则（可能使用 规范 模式：例如 EligibleForPartnershipSpecification)
当更改组织的业务部门，最好考虑 “手术可以进行吗？”而不是“这个实体有效吗？”。这可能意味着检查公司存储库中的公司是否具有在修改后变得不一致的合作伙伴关系，并相应地决定要做什么（可能基于策略/策略模式）。
合同是强制不变量的另一种明智方式：请参阅 http://msdn.microsoft.com /en-us/magazine/hh205755.aspx (.NET)
I see 2 DDD-compliant ways of enforcing this business rule :
DDD specifies that invariants in an Aggregate should be enforced by the Aggregate Root. If Company is your aggregate root, when you add a new partnership to it, it could check if the partnership complies with the business sector rule (possibly using a Specification pattern : EligibleForPartnershipSpecification for instance)
When changing an organization's business sector, it's a good idea to think in terms of "can the operation be performed ?" rather than "is this entity valid ?". It might mean checking if a Company in the company repository has a Partnership that would become inconsistent after the modification and decide what to do (possibly based on a Policy / Strategy pattern) accordingly.
Contracts are another smart way of enforcing invariants : see http://msdn.microsoft.com/en-us/magazine/hh205755.aspx (.NET)
你的解释有问题。此设计中没有聚合根。
但从逻辑上讲，以下陈述可能存在冲突
并且
如果这样做，您必须避免其中之一。
如果（2）为假，那么一切都很好，对吧？你只是不允许这样的改变。
如果（1）是错误的（或者更确切地说，没有那么严格），那么组织与业务部门的界限也应该限制在一定的时间内。在这种情况下，您可以采用与合伙期限限制相同的方式进行。
例如，您可以将 Partnership.EndDate 设置为组织 -> 部门链接更改的日期。
此外，您还可以维护参与的部门组织的一些历史列表。业务规则将强制执行合作伙伴关系和部门分配的期间匹配。
希望有帮助。 （实际上通用设计问题应该去程序员网站。）
Something goes wrong in your explanation. There are no aggregate roots in this design.
But logically probably the following statements conflict
and
If they do, you must avoid one of them.
If (2) is false, then everything is fine, right? You just don't allow such a change.
If (1) is false (or rather, not so restrictive), then organization bounds with business sector also should be limited to a certain period of time. In that case you make it in the same fashion like partnership's period limitation.
For example, you could set Partnership.EndDate to the date of Organization->Sector link change.
Additionally you could maintain some historical list of Sectors Organization participated in. Business rules would enforce periods match for Partnership and Sector assignment.
Hope that helps. (And actually generic design questions should go to programmers site.)