什么是领域模型(domain model)?贫血模型(anaemic domain model) 和充血模型(rich domain model)有什么区别

http://blog.csdn.net/helloboat/article/details/51208128

领域模型是领域内的概念类或现实世界中对象的可视化表示,又称为概念模型或分析对象模型,它专注于分析问题领域本身,发掘重要的业务领域概念,并建立业务领域概念之间的关系。贫血模型是指使用的领域对象中只有setter和getter方法(POJO),所有的业务逻辑都不包含在领域对象中而是放在业务逻辑层。有人将我们这里说的贫血模型进一步划分成失血模型(领域对象完全没有业务逻辑)和贫血模型(领域对象有少量的业务逻辑),我们这里就不对此加以区分了。充血模型将大多数业务逻辑和持久化放在领域对象中,业务逻辑(业务门面)只是完成对业务逻辑的封装、事务和权限等的处理。下面两张图分别展示了贫血模型和充血模型的分层架构。

贫血模型

充血模型

贫血模型下组织领域逻辑通常使用事务脚本模式,让每个过程对应用户可能要做的一个动作,每个动作由一个过程来驱动。也就是说在设计业务逻辑接口的时候,每个方法对应着用户的一个操作,这种模式有以下几个有点:

  1. 它是一个大多数开发者都能够理解的简单过程模型(适合国内的绝大多数开发者)。
  2. 它能够与一个使用行数据入口或表数据入口的简单数据访问层很好的协作。
  3. 事务边界的显而易见,一个事务开始于脚本的开始,终止于脚本的结束,很容易通过代理(或切面)实现声明式事务。

然后,事务脚本模式的缺点也是很多的,随着领域逻辑复杂性的增加,系统的复杂性将迅速增加,程序结构将变得极度混乱。

时间: 2024-10-21 23:02:45

什么是领域模型(domain model)?贫血模型(anaemic domain model) 和充血模型(rich domain model)有什么区别的相关文章

领域模型(domain model)&贫血模型(anaemic domain model)&充血模型(rich domain model)

领域模型是领域内的概念类或现实世界中对象的可视化表示,又称为概念模型或分析对象模型,它专注于分析问题领域本身,发掘重要的业务领域概念,并建立业务领域概念之间的关系. 贫血模型是指使用的领域对象中只有setter和getter方法(POJO),所有的业务逻辑都不包含在领域对象中而是放在业务逻辑层.有人将我们这里说的贫血模型进一步划分成失血模型(领域对象完全没有业务逻辑)和贫血模型(领域对象有少量的业务逻辑),就不对此加以区分了. 充血模型将大多数业务逻辑和持久化放在领域对象中,业务逻辑(业务门面)

贫血,充血模型的解释以及一些经验

为了补大家的遗憾,在此总结下ROBBIN的领域模型的一些观点和大家的补充,在网站和演讲中,robbin将领域模型初步分为4大类: 1,失血模型 2,贫血模型 3,充血模型 4,胀血模型 那么让我们看看究竟有这些领域模型的具体内容,以及他们的优缺点: 一.失血模型 失血模型简单来说,就是domain object只有属性的getter/setter方法的纯数据类,所有的业务逻辑完全由business object来完成(又称Transaction Script),这种模型下的domain obje

极客设计模式之美学习-传统MVC和DDD充血模型(二)

贫血模型 贫血模型例子 现在传统的MVC开发基本上都是贫血模型 如以下代码 我们工作中经常使用 ////////// Controller+VO(View Object) ////////// public class UserController { private UserService userService; //通过构造函数或者IOC框架注入 public UserVo getUserById(Long userId) { UserBo userBo = userService.get

领域模型、贫血模型、充血模型概念总结

领域模型 领域模型是对领域内的概念类或现实世界中对象的可视化表示.又称概念模型.领域对象模型.分析对象模型.它专注于分析问题领域本身,发掘重要的业务领域概念,并建立业务领域概念之间的关系. 业务对象模型(也叫领域模型 domain model)是描述业务用例实现的对象模型.它是对业务角色和业务实体之间应该如何联系和协作以执行业务的一种抽象.业务对象模型从业务角色内部的观点定义了业务用例.该模型为产生预期效果确定了业务人员以及他们处理和使用的对象(“业务类和对象”)之间应该具有的静态和动态关系.它

贫血模型跟充血模型-摘录

贫血模型:是指领域对象里只有get和set方法,或者包含少量的CRUD方法,所有的业务逻辑都不包含在内而是放在Business Logic层. 优点是系统的层次结构清楚,各层之间单向依赖,Client->(Business Facade)->Business Logic->Data Access(ADO.NET).当然Business Logic是依赖Domain Object的.似乎现在流行的架构就是这样,当然层次还可以细分. 该模型的缺点是不够面向对象,领域对象只是作为保存状态或者传

贫血模型和充血模型

贫血模型:领域对象里只有get和set方法,或者包含少量的CRUD方法,而不包含有业务逻辑的处理,把"行为"和"状态"分离到不同的对象里,只有状态的对象被称为"贫血对象"(VO),而只有"行为"的对象一般被用作服务对象,就像spring的server一样,都是无状态对象,本身并不存储数据,只处理逻辑. 充血模型:业务逻辑和持久化都放在对象中,Business Logic(业务逻辑层)只负责简单封装部分业务逻辑以及控制事务.权限

从经典架构项目中透析微服务架构的核心概念和充血模型

微服务架构和SOA区别 微服务现在辣么火,业界流行的对比的却都是所谓的Monolithic单体应用,而大量的系统在十几年前都是已经是分布式系统了,那么微服务作为新的理念和原来的分布式系统,或者说SOA(面向服务架构)是什么区别呢? 我们先看相同点: 需要Registry,实现动态的服务注册发现机制:需要考虑分布式下面的事务一致性,CAP原则下,两段式提交不能保证性能,事务补偿机制需要考虑:同步调用还是异步消息传递,如何保证消息可靠性?SOA由ESB来集成所有的消息:都需要统一的Gateway来汇

失血模型,充血模型

一.失血模型 失血模型简单来说,就是domain object只有属性的getter/setter方法的纯数据类. 简单来说,就是domain ojbect包含了不依赖于持久化的领域逻辑,而那些依赖持久化的领域逻辑被分离到Service层. Service(业务逻辑,事务封装) --> DAO ---> domain object 这种模型的优点: 1.各层单向依赖,结构清楚,易于实现和维护 2.设计简单易行,底层模型非常稳定 这种模型的缺点: 1.domain object的部分比较紧密依赖

领域驱动模型和以数据为中心模型的一些思考

假设有如下业务逻辑: 我要搬到新地方去工作. 代码1: class Player { public: void setAddr(string name); void setJob(string job); private: string _name; string _job; } 代码2: class Player { public: void changeAddr(string name); void changeJob(string job); private: string _name;