现在做网站一般做多宽,微信网页注册入口,工业和信息化部投诉平台入口,数据中台主要实现哪些功能UML#xff1a;聚合关系#xff1a;成员对象是整体的一部分#xff0c;但是成员对象可以脱离整体对象独立存在。如汽车#xff08;Car#xff09;与引擎#xff08;Engine#xff09;、轮胎#xff08;Wheel#xff09;、车灯#xff08;Light#xff09;之间的关系… UML聚合关系成员对象是整体的一部分但是成员对象可以脱离整体对象独立存在。如汽车Car与引擎Engine、轮胎Wheel、车灯Light之间的关系为聚合关系引擎、轮胎、车灯可以脱离车而存在比如把一个引擎换到另一个汽车上也可以。组合关系也表示的是一种整体和部分的关系但是在组合关系中整体对象可以控制成员对象的生命周期一旦整体对象不存在成员对象也不存在整体对象和成员对象之间具有同生共死的关系。所以聚合和组合的差别就一点整体和部分的生命周期是否一致即整体消亡后成员对象是否可以脱离整体对象而单独存在。DDD聚合关系也是一种整体和部分的关系部分脱离整体会变得毫无意义强调同生共死的一致的生命周期。所以从定义来看DDD中的聚合应该和UML中的组合关系是一致的。按照上面的定义我们在来分析一下一个典型的例子就是公司和部门的关系。UML的角度1、一个公司由多个部门组成所以满足整体和部分的关系2、一个部门不能脱离公司和加入到其他公司所以在UML中应该属于组合关系没有问题。DDD的角度虽然基于UML的角度公司和部门属于组合关系那在DDD中是否应该把部门聚合在公司下面呢我的看法是虽然从生命周期上确实部门不能脱离公司。但是DDD的聚合设计要考虑的因素会更加丰满比如DDD强调需求和Bounded Context也就是会基于需求和上下文进行建模我们建模前必须要先确定当前的需求和上下文是什么整体在当前上下文是否强关心部分的存在整体和部分之间是否存在某些不变性规则操作整体与操作部分的业务场景是否一致性能问题如果整体聚合的部分数量过大那也不会考虑聚合即小聚合原则一致性问题我们在设计系统时即便把本该是聚合在一起的对象分开设计为多个聚合也可以从技术上去解决一致性比如通过领域服务来完成多个聚合的协同创建、删除、修改并能通过数据库事务来保证严格的强一致性DDD领域建模会对领域概念进行抽象所以再领域模型中也许就没有公司了而是只有部门把公司也看成是一个顶层的部门就行所以自然就不会有公司这个聚合根了所以在进行DDD聚合设计时如果仅从整体删除后部分会变得毫无意义(即对象之间的生命周期)这个点去推导的话那考虑的就太单薄了很有可能会得出不合理的聚合设计。这是没有认真分析业务需求没有分析业务规则不变性没有对领域概念进行合理抽象没有进行OO软件设计原则的应用的表现。我想这也是为什么DDD聚合设计为何会如此之难的原因了。所以结论是以上案例由于需求不明无法进行聚合设计大家是不是很意外呢居然没有给出答案:)原文地址https://www.cnblogs.com/netfocus/p/11078464.html
