这两个概念是早些时候Martin Fowler总结出来的两种常见模型设计类型,没有说谁好谁不好,为不同的模型类别选择合适的场景是设计者的工作。没有工具本身的问题,只有工具使用者的问题。
贫血模型是指领域对象里只有get和set方法(POJO),所有的业务逻辑都不包含在内而是放在Business Logic层。
优点是系统的层次结构清楚,各层之间单向依赖,Client->(Business Facade)->Business Logic->Data Access Object。可见,领域对象几乎只作传输介质之用,不会影响到层次的划分。
该模型的缺点是不够面向对象,领域对象只是作为保存状态或者传递状态使用,它是没有生命的,只有数据没有行为的对象不是真正的对象,在Business Logic里面处理所有的业务逻辑,对于细粒度的逻辑处理,通过增加一层Facade达到门面包装的效果。
在使用Spring的时候,通常暗示着你使用了贫血模型,我们把Domain类用来单纯地存储数据,Spring管不着这些类的注入和管理,Spring关心的逻辑层(比如单例的被池化了的Business Logic层)可以被设计成singleton的bean。
假使我们这里逆天而行,硬要在Domain类中提供业务逻辑方法,那么我们在使用Spring构造这样的数据bean的时候就遇到许多麻烦,比如:bean之间的引用,可能引起大范围的bean之间的嵌套构造器的调用。
贫血模型实施的最大难度在于如何梳理好Business Logic层内部的划分关系,由于该层会比较庞大,边界不易控制,内部的各个模块之间的依赖关系不易管理,可以考虑这样这样的实现思路:
(1)铺设扁平的原子业务逻辑层,即简单的CRUD操作(含批量数据操作);
(2)特定业务清晰的逻辑通过Facade层来组装原子操作实现。
(3)给业务逻辑层实施模块划分,保持模块之间的松耦合的关系。
举例说明:
原子业务逻辑层(Service)提供了用户模型的条件查询方法:
List<User> queryUser(Condition con)
Facade层则提供了一种特定的业务场景的分子接口,满足18岁的中国公民,内部实现调用的正是上述的原子接口:
List<User> queryAdultChinese()
Facade、Service层纵向划分为几个大的领域包:用户、内容和产品。
充血模型层次结构和上面的差不多,不过大多业务逻辑和持久化放在Domain Object里面,Business Logic只是简单封装部分业务逻辑以及控制事务、权限等,这样层次结构就变成Client->(Business Facade)->Business Logic->Domain Object->Data Access Object。
它的优点是面向对象,Business Logic符合单一职责,不像在贫血模型里面那样包含所有的业务逻辑太过沉重。
缺点是如何划分业务逻辑,什么样的逻辑应该放在Domain Object中,什么样的业务逻辑应该放在Business Logic中,这是很含糊的。即使划分好了业务逻辑,由于分散在Business Logic和Domain Object层中,不能更好的分模块开发。熟悉业务逻辑的开发人员需要渗透到Domain Logic中去,而在Domian Logic又包含了持久化,对于开发者来说这十分混乱。 其次,如果Business Logic要控制事务并且为上层提供一个统一的服务调用入口点,它就必须把在Domain Logic里实现的业务逻辑全部重新包装一遍,完全属于重复劳动。
使用RoR开发时, 每一个领域模型对象都可以具备自己的基础业务方法,通常满足充血模型的特征。充血模型更加适合较复杂业务逻辑的设计开发。
充血模型的层次和模块的划分是一门学问,对开发人员要求亦较高,可以考虑定义这样的一些规则:
(1)事务控制不要放在领域模型的对象中实现,可以放在facade中完成。
(2)领域模型对象中只保留该模型驱动的一般方法,对于业务特征明显的特异场景方法调用放在facade中完成。
万事都不是绝对的,也有一些看起来不易解决的问题。例如,考虑到性能的需要,我需要一次查询出满足某种条件的用户和某种条件的产品,他们二者之间通过订购关系关联起来,可能发现这种情形下,上述的模型层次划分变得无解了……
怎么办呢?包括以上种种,欢迎大家讨论。
- 大小: 21 KB
- 大小: 15.7 KB
分享到:
相关推荐
失血模型简单来说,就是domain object只有属性的getter/setter方法的纯数据类,所有的业务逻辑完全由business object来完成(又称TransactionScript),这种模型下的domain object被Martin Fowler称之为“贫血的domain...
本文解释了当今比较新的设计模式中的贫血和充血模式。对加深理解二模型很有帮助!
第一点原因是,大部分情况下,我们开发的系统业务可能都比较简单,简单到就是基于 第二点原因是,充血模型的设计要比贫血模型更加有难度 第三点原因是,思维已固化,转型
NULL 博文链接:https://melin.iteye.com/blog/716507
贫血模型or领域模型的举例对比,让你初步了解贫血模型与领域模型的区别和概念。附加一个自己创建的代码范例
(1)每一个数据库表对应创建一个类,类的每一个对象实例对应于数据库中表 (2)领域对象同事封装了业务逻辑 (3)领域对象同时负责数据持久化,在其中封装对数据库的
基于GO的六边形架构框架,可支撑充血的领域模型范式代码实现
微服务架构首先要关注的不是RPC/ServiceDiscovery/Circuit Breaker这些概念,也不是Eureka/Docker/SpringCloud/Zipkin这些技术框架,而是服务的边界、职责划分,划分错误就会陷入大量的服务...• 充血模型 • 事件驱动
如果领域模型只是用来处理简单的逻辑(比如贫血模型),那么领域模型的作用微乎其微,甚至可以忽略,数据转换的成本比领域模型带来的好处还多,这种情况其实就是在原有的分层架构中多加了一层,增加了项目的复杂性和...
全身性炎症反应综合征(SIRS)是伴发状态之一,可加重充血性心力衰竭(CHF)的严重程度并使难治性CHF转向常规治疗。 我们调查了SIRS症状和体征的停止是否会阻止兔慢性主动脉瓣狭窄引起的CHF进展。 冠状动脉左降支...
贫血模型的优缺点? DDD提倡的充血模型是什么? 体会下充血模型开发微信钱包系统 聚合和聚合根是什么? 领域事件是什么? 看看领域事件的本质(解耦,异步,削峰) 工厂和资源库的作用? 领域服务是什么? 通过用例...
火龙果软件工程技术中心 对于领域模型这个概念,以前没有系统性的认识,只是根据经验,在设计系统时自发的在使用....domainobject3、充血模型Service(事务封装)--->domainobject<--->DAO4、胀血模
1. 充值 2. 支付 3. 提现 4. 查询余额 5. 查询交易流水
在这里,我们报告一例74岁的女性患者,该患者被诊断为孤立的左心室非紧密性充血性心力衰竭,壁内血栓和高血压。 LVNC没有特定的治疗方法。 治疗措施针对患者的症状(心力衰竭,心律不齐和血栓形成事件),并考虑...
我们研究了左心室射血分数,充血性心力衰竭的严重程度,血清尿酸水平和众所周知的常规危险因素之间的关系。 结果:主要发现是充血性心力衰竭患者的平均血清尿酸水平明显高于“ P值= 0.02”的健康人群。 当我们在...
充血性心力衰竭急诊治疗.ppt
自由DDD框架自由是一个基于六边形架构的框架,可以支撑充血的领域模型范式。总览集成虹膜HTTP / H2C服务器和客户端集成普罗米修斯AOP工作者和无侵入上下文可扩展组件依赖注入&依赖倒置&开闭原则DDD和六边形架构...
在这项研究中,作者提出了一种新的方法来评估React性充血的React,其粘弹性指数包括使用应变仪体积描记法在逐次搏动的基础上测得的刚度和粘度。 为了研究所提出方法的有效性,进行了评估以确定在React性充血中React...
背景:在我们所在的重症监护病房中,充血性心力衰竭(CHF)的数据很少。 这项研究旨在为雅温得大学教学医院的重症监护病房提供更好的CHF模式和预后知识。 方法:我们进行了为期21个月的描述性和回顾性研究。 我们从...