问题标签 [anemic-domain-model]
For questions regarding programming in ECMAScript (JavaScript/JS) and its various dialects/implementations (excluding ActionScript). Note JavaScript is NOT the same as Java! Please include all relevant tags on your question; e.g., [node.js], [jquery], [json], [reactjs], [angular], [ember.js], [vue.js], [typescript], [svelte], etc.
c# - 实体框架 - 不同于域模型的持久性模型
我有以下旧代码。持久模型和(贫血的)域模型之间存在分离。这种分离和隐式转换有什么好处?你看到什么缺点了吗?
我知道使用隐式转换是可能的:SplitAmountEF saEF = dbContext.SplitAmount.Find(id); 拆分金额 sa = saEF; //隐式转换。它们可以互换使用。
如果领域模型和持久性模型几乎一样,那么只使用持久性模型(根本不使用域模型)会更好吗?
例子:
domain-driven-design - DDD 与贫血域模型
你能告诉我模型贫血域模型和DDD有什么区别吗?现在最常用的是什么?使用spring框架(spring data ...)的应用程序时,哪个模型是相关的?
service - 将服务引用放入域模型的架构缺点?(爪哇)
该主题是指下面的解决方案,并想知道它在通用上下文和特定上下文中有什么缺点。
需要回答的问题:
- 在 Java 世界中应该为这种问题/应用程序选择什么样的架构?(一般上下文)
- 以下对应用程序建模的方法有什么缺点?
- 对于给定的上下文,提出的解决方案是否可以接受?(具体情况)
一般上下文:
我们有一种带有流处理主管道的应用程序。我们称这个应用为 AnimalSpecialDayCycle。将此视为“动物酒店的特殊日子”。
动物会一只一只来,酒店会为它们度过特别的一天,为它们提供食物、训练、繁殖和良好的睡眠。
让我们考虑一个贫血的域模型,例如:
建议的解决方案:
我们将此应用程序拆分为不同的模块(单独的应用程序),这些模块通过称为“动物”的通用域模型(转换为 JSON|XML)在它们之间进行通信。
他们使用的动物和服务实施示例:
- 狗(MeatEattingService、RunningTrainService、InseminationBreedingService、LaydownSleepingService)
- 马(VegetableEattingService、RunningTrainService、
InseminationBreedingService、StandingSleepingService) - Aligator(MeatEattingService、SwimmingTrainService、EggsBreedingService、UnderwaterSleepingService)
- Parrot(VegetableEattingService、FlyableTrainService、EggsBreedingService、FlyableSleepingService)
现在,我建议在每个模块中扩展 Animal 域模型,例如:
其他模块也一样。
当动物进入一个模块并且我们从 JSON|XML(或任何 fromat 具有来自前一个模块的消息)创建对象时,我们还为该模块设置了正确的服务实现。
(例如:如果 Shark 进入 EatModule,我们将在其 eattingServiceInterface 字段上设置其类型的正确实现。)
实际上,我正在寻找一种保持多态性的方法,但要将行为与对象状态分开,保持贫血的域模型。
我看到的优点:
- 在自己的类中解耦业务行为,能够轻松修改它们
- 在这种面向服务的架构和贫血模型中,多态性和避免复杂的“ifs”结构和混乱的代码
缺点:
- 依赖关系:域依赖于服务和服务在域上
具体上下文:
我们从头开始开发这种应用程序,假设我们已经完成了 50%(已经投入了大量精力)。
我们在每个模块中都需要“Animal”对象,因为在模块结束时,我们会发送一个带有 Animal 对象“新状态”的“事件”。
我对事情的发展方式不满意。现在,当我们进行开发时,我们只是在代码中打了很多“ifs”。
我们没有子类,因为当我提议创建它们时,我们不应该仅仅因为我们在一个字段上具有不同的值而创建子类,该字段可能只使用一次来执行“if”语句模块之一。
现在我认为我们需要的是多态性,但是没有机会摆脱 SOA 和贫血的领域模型,所以我在考虑上面的解决方案。
oop - 这是否被视为程序编程(或贫血模式)?
假设有两个类,一个是用户类,其中包含用户信息;另一个是支付交易类。场景很简单,如果用户年龄>65岁,创建A类支付交易;否则,创建 B 类支付交易。
做这件事有很多种方法:
- 创建一个既不属于用户也不属于事务的方法,只需调用 CreateTransaction。此方法中说明了逻辑:
- 另一个选项是为用户类创建方法:
然后有一个 CreateTransactionController 方法调用该函数,如:
我的问题是,选项 1 是否被视为过程编程,因为逻辑实际上不属于任何对象?(或贫血模式?) 1 和 2 之间的区别是否只是放置逻辑的不同位置?
谢谢!
jpa - 向 JPA 实体添加业务逻辑
在下一个场景中,我必须将一些带有 JPA 规范的静态过滤器(添加 WHERE 子句)应用到 JPA 实体以获取过滤的狗列表,例如,我从实体收到一个 id,我必须应用相同的过滤器但为每个未完成的过滤器发送错误消息。例如:拥有实体 Dog,我收到一个 id,使用 JPA 获取该实体并应用一些过滤器,例如狗年龄>3 岁等...
我的想法是重用 JPA 规范来做到这一点,但使用它们不会给我关于为什么我没有得到实体以及没有完成哪个过滤器以发送错误消息的信息。
我所做的是将 isDogOlderThan3Years() 之类的方法添加到 JPA 实体中,并且实体本身会为每个过滤器询问其属性等。我认为这与非贫血实体有关。这是一个好/坏的解决方案吗?有更好的吗?
谢谢
domain-driven-design - 富域模型应用程序中的持久性和域层分离
有一个概念谈到了将 与 分离persistent layer
以domain layer
使domain layer
更健壮 - 它不依赖于存储库的实际实现persistence layer
,而仅依赖于存储库接口。
这意味着我们有:
现在,怎么样Person
?
在anemic-domain-model
我们可以有:
为什么要把 Person 放在持久层?
因为它包含特定于实现的代码。
例如,它可能包含与 JPA 相关的注释,并且与存储库相同,我们不希望在我们的域层中实现数据存储特定的实现。
我们可以使用anemic-domain-model来完成上述操作,因为 Person 不包含任何域逻辑,这意味着我们可以将 Person 放在持久层中。
在贫血域模型中,数据与行为是分离的,因此 Person 的行为是由分离的服务完成的,而不是写在 Person 本身中。
我们不能使用rich-domain-model进行这种层分离,因为在这种情况下, Person 确实包含特定于域的逻辑。
您将如何在富域模型应用程序中进行这种层分离?
或者,也许您认为不需要它。