Ili*_*akh 2 domain-driven-design
当您以OO/DDD样式开发体系结构并为某个域实体建模时,例如Order实体,您将整个逻辑相关的顺序放入Order实体.但是当应用程序变得更加复杂时,Order实体会收集越来越多的逻辑,而这个类变得非常庞大.与贫血模型相比,是的,它显然是一种反模式,但所有这些巨大的逻辑在不同的服务中是分开的.
是否可以处理庞大的域实体或我理解错误？
当您尝试创建富域模型时,请将实体集中在身份和生命周期上,从而尽量避免它们因属性或行为而变得臃肿.
域服务可能是放置行为的地方,但我倾向于看到许多域服务方法具有更好地分配给值对象的行为,因此我不会通过将行为移动到域服务来开始重构.域服务往往在与当前域模型之外的事物连接之前作为直接的外观/适配器工作得最好(即屏蔽基础设施问题).
您还可以将行为放在应用程序服务中,但要问问自己该行为是否属于域模型之外.作为一般规则,尝试将应用程序服务更多地集中在跨越实体,域服务,存储库的编排式任务上.
遇到膨胀的实体时,首先要做的是查找一组具有凝聚力的实体属性和相关行为,并通过将这些隐式概念提取到值对象中来使这些隐式概念显式化.然后,实体可以将其行为委托给这些值对象.
由于我们都倾向于对实体更加满意,因此尝试更偏向于价值对象,这样您就可以获得价值对象提供的不变性,封装和可组合性的好处 - 让您转向更灵活的设计.
使用值对象,您可以将更多功能样式(例如,无副作用的函数)合并到域模型中,从而使您的实体免于处理将复杂行为添加到管理身份和生命周期负担的复杂性.有关详细信息,请参阅Eric Evan的http://domainlanguage.com/ddd/patterns/和蓝皮书中的实体和值对象的模式摘要.
小智 6
当您以OO/DDD样式开发体系结构并为某个域实体建模时,例如Order实体,您将整个逻辑相关的顺序放入Order实体.但是当应用程序变得更加复杂时,Order实体会收集越来越多的逻辑,而这个类变得非常庞大.
倾向于变得庞大的类通常是具有重叠职责的类.Order是一个典型的类,它可以有多个职责,可以在您的应用程序中扮演不同的角色.
鉴于背景下的订单出现,它可能是一个实体的可变状态(即,如果你管理秩序的商业条件,在一个协商阶段),但如果你的应用程序管理物流,一个订单可能会发挥不同的作用:并且不可变的Value Object可能是逻辑上下文中的最佳实现.
与贫血模型相比,是的,它显然是一种反模式,但所有这些巨大的逻辑在不同的服务中是分开的.
...... 分离是件好事.:-)
我有一种感觉,原始模型可能以数据为中心,数据服务于不同目的(订单创建,付款,订单履行,订单交付)堆积在同一个容器(Order类)中.不能从这里说出来,但这是一个非常频繁的模式.并非所有这些数据都可以同时用于同一目的.
通常,像你所描述的那样膨胀的类是有界上下文之间缺失分离的气味,和/或在同一有界上下文中不完整的聚合分离.我想看看:
并尝试相应地重新定义聚合边界.还有:
当涉及到发现所涉及的背景时.
在大型应用程序中,您可能拥有多个模型,从而导致单个域概念的多个表示形式,至少对于扮演多个角色的概念而言.
这是保罗方法的补充.