精华内容
下载资源
问答
  • 什么是基于贫血模型的传统开发模式? 对于大部分的后端开发工程师来说,MVC 三层架构都不会陌生。它将整个项目分为三层:展示层、逻辑层、数据层。...什么是基于充血模型DDD 开发模式? 在贫血模

    什么是基于贫血模型的传统开发模式?

    对于大部分的后端开发工程师来说,MVC 三层架构都不会陌生。它将整个项目分为三层:展示层、逻辑层、数据层。MVC 三层开发架构是一个比较笼统的分层方式。

    像 UserBo 这样,只包含数据,不包含业务逻辑的类,就叫作贫血模型(Anemic Domain Model)。同
    理,UserEntity、UserVo 都是基于贫血模型设计的。这种贫血模型将数据与操作分离,破坏了面向对象的封装特性,是一种典型的面向过程的编程风格。

    什么是基于充血模型的 DDD 开发模式?

    在贫血模型中,数据和业务逻辑被分割到不同的类中。充血模型(Rich Domain Model)正好相反,数据和对应的业务逻辑被封装到同一个类中。因此,这种充血模型满足面向对象的封装特性,是典型的面向对象编程风格

    领域驱动设计,即 DDD,主要是用来指导如何解耦业务系统,划分业务模块,定义业务领域模型及其交互。

    在基于充血模型的 DDD 开发模式中,Service 层包含 Service 类和 Domain 类两部分。Domain 就相当于贫血模型中的 BO。不过,Domain 与 BO 的区别在于它是基于充血模型开发的,既包含数据,也包含业务逻辑。而 Service 类变得非常单薄。

    基于充血模型的 DDD 开发模式,跟基于贫血模型的传统开发模式的主要区别就在 Service 层,Controller 层和 Repository 层的代码基本上相同

    总结一下的话就是,基于贫血模型的传统的开发模式,重 Service 轻 BO;基于充血模型的 DDD 开发模式,轻 Service 重Domain

    为什么基于贫血模型的传统开发模式如此受欢迎?

    1、大部分情况下,我们开发的系统业务可能都比较简单,简单到就是基于SQL 的 CRUD 操作,所以,我们根本不需要动脑子精心设计充血模型,贫血模型就足以应付这种简单业务的开发工作。
    2、充血模型的设计要比贫血模型更加有难度。因为充血模型是一种面向对象的编程风格。我们从一开始就要设计好针对数据要暴露哪些操作,定义哪些业务逻辑。而不是像贫血模型那样,我们只需要定义数据,之后有什么功能开发需求,我们就在 Service 层定义什么操作,不需要事先做太多设计。
    3、思维已固化,转型有成本。

    什么项目应该考虑使用基于充血模型的 DDD 开发模式?

    **基于贫血模型的传统的开发模式,比较适合业务比较简单的系统开发。相对应的,基于充血模型的 DDD 开发模式,更适合业务复杂的系统开发。**比如,包含各种利息计算模型、还款模型等复杂业务的金融系统。

    你可能会有一些疑问,这两种开发模式,落实到代码层面,区别不就是一个将业务逻辑放到Service 类中,一个将业务逻辑放到 Domain 领域模型中吗?为什么基于贫血模型的传统开发模式,就不能应对复杂业务系统的开发?而基于充血模型的 DDD 开发模式就可以呢?

    答案:除了代码层面,两种不同的开发模式会导致不同的开发流程。

    我们平时的开发,大部分都是 SQL 驱动(SQL-Driven)的开发模式。我们接到一个后端接口的开发需求的时候,就去看接口需要的数据对应到数据库中,需要哪张表或者哪几张表,然后思考如何编写 SQL 语句来获取数据。之后就是定义 Entity、BO、VO,然后模板式地往对应的 Repository、Service、Controller 类中添加代码。

    业务逻辑包裹在一个大的 SQL 语句中,而 Service 层可以做的事情很少。SQL 都是针对特定的业务功能编写的,复用性差。当我要开发另一个业务功能的时候,只能重新写个满足新需求的 SQL 语句,这就可能导致各种长得差不多、区别很小的 SQL 语句满天飞。

    所以,在这个过程中,很少有人会应用领域模型、OOP 的概念,也很少有代码复用意识。对于简单业务系统来说,这种开发方式问题不大。但对于复杂业务系统的开发来说,这样的开发方式会让代码越来越混乱,最终导致无法维护。

    如果我们在项目中,应用基于充血模型的 DDD 的开发模式,那对应的开发流程就完全不一样了。在这种开发模式下,我们需要事先理清楚所有的业务,定义领域模型所包含的属性和方法。领域模型相当于可复用的业务中间层。新功能需求的开发,都基于之前定义好的这些领域模型来完成。

    我们知道,越复杂的系统,对代码的复用性、易维护性要求就越高,我们就越应该花更多的时间和精力在前期设计上。而基于充血模型的 DDD 开发模式,正好需要我们前期做大量的业务调研、领域模型设计,所以它更加适合这种复杂系统的开发。

    在基于充血模型的 DDD 开发模式中,将业务逻辑移动到Domain 中,Service 类变得很薄,但在我们的代码设计与实现中,并没有完全将Service 类去掉,这是为什么?或者说,Service 类在这种情况下担当的职责是什么?哪些功能逻辑会放到 Service 类中?

    1、Service 类负责与 Repository 交流。在我的设计与代码实现中,VirtualWalletService类负责与 Repository 层打交道,调用 Respository 类的方法,获取数据库中的数据,转化成领域模型 VirtualWallet,然后由领域模型 VirtualWallet 来完成业务逻辑,最后调用Repository 类的方法,将数据存回数据库。

    之所以让 VirtualWalletService 类与 Repository 打交道,而不是让领域模型 VirtualWallet 与 Repository 打交道,那是因为我们想保持领域模型的独立性,不与任何其他层的代码(Repository 层的代码)或开发框架(比如 Spring、MyBatis)耦合在一起,将流程性的代码逻辑(比如从 DB 中取数据、映射数据)与领域模型的业务逻辑解耦,让领域模型更加可复用。

    2、Service 类负责跨领域模型的业务聚合功能。VirtualWalletService 类中的 transfer() 转账函数会涉及两个钱包的操作,因此这部分业务逻辑无法放到 VirtualWallet 类中,所以,我们暂且把转账业务放到 VirtualWalletService 类中了。当然,虽然功能演进,使得转账业务变得复杂起来之后,我们也可以将转账业务抽取出来,设计成一个独立的领域模型。

    3、Service 类负责一些非功能性及与三方系统交互的工作。比如幂等、事务、发邮件、发消息、记录日志、调用其他系统的 RPC 接口等,都可以放到 Service 类中。

    在基于充血模型的 DDD 开发模式中,尽管 Service 层被改造成了充血模型,但是 Controller 层和 Repository 层还是贫血模型,是否有必要也进行充血领域建模呢?

    答案是没有必要。Controller 层主要负责接口的暴露,Repository 层主要负责与数据库打交道,这两层包含的业务逻辑并不多,前面我们也提到了,如果业务逻辑比较简单,就没必要做充血建模,即便设计成充血模型,类也非常单薄,看起来也很奇怪。

    尽管这样的设计是一种面向过程的编程风格,但我们只要控制好面向过程编程风格的副作用,照样可以开发出优秀的软件。那这里的副作用怎么控制呢?

    就拿 Repository 的 Entity 来说,即便它被设计成贫血模型,违反面相对象编程的封装特性,有被任意代码修改数据的风险,但Entity 的生命周期是有限的。一般来讲,我们把它传递到 Service 层之后,就会转化成 BO 或者 Domain 来继续后面的业务逻辑。Entity 的生命周期到此就结束了,所以也并不会被到处任意修改。

    我们再来说说 Controller 层的 VO。实际上 VO 是一种 DTO(Data Transfer Object,数据传输对象)。它主要是作为接口的数据传输承载体,将数据发送给其他系统。从功能上来讲,它理应不包含业务逻辑、只包含数据。所以,我们将它设计成贫血模型也是比较合理的。

    展开全文
  • 这几年,状态依旧不好,但在23点以后,状态还可以,所以,静下来,看点DDD,并把相关信息记载一下,今天是除夕,不过,我写文章时已经是大年初一了,呵呵,外面的炮声响亮,但我的内心很平静,也许是年龄大了,对于...

    这几年,状态依旧不好,但在23点以后,状态还可以,所以,静下来,看点DDD,并把相关信息记载一下,今天是除夕,不过,我写文章时已经是大年初一了,呵呵,外面的炮声响亮,但我的内心很平静,也许是年龄大了,对于过年的感觉也已经淡化了吧,再或许是有些事情还放不在。

    任务与目标

    今年的任务挺多的,目标也确实有点大,压我的有点喘不过气来,对于年未,我们是放松的,因为一年的任何已经完成,目录也已经完成,所以是放松的;但当新的一年真的到来时,意味着你要去实现今年定的目标了,我们需要紧张起来了,需要向着那个目标去奋斗了,这种感觉是我喜欢的!

    失血模型

    失血模型简单来说,就是domain object只有属性的getter/setter方法的纯数据类,所有的业务逻辑完全由business object来完成,这种模型下的domain object被Martin Fowler称之为“贫血的domain object”

    充血模型

    将大部分单个的,自身的,逻辑都定义在domain object里,包括持久化逻辑,而BLL层只负责事务处理和逻辑组合,BLL层在这里不直接访问DATA层,它的调用图示一般为:

    BLL(业务组合,事务封装)=>domain object领域对象=>DAO(数据访问对象)

    OK,对于领域驱动设计,我们对传统的POCO实体要进行必要的扩充,以符合DDD的原则。

    相关文章

    DDD~概念中的DDD

    DDD~充血模型和失血模型

    DDD~基础设施层

    DDD~microsoft NLayerApp项目中的层次结构图

    DDD~领域层

    DDD~Unity在DDD中的使用

    本文转自博客园张占岭(仓储大叔的博客,原文链接:DDD~充血模型和失血模型,如需转载请自行联系原博主。

    展开全文
  • DDD领域模型  官方说法  领域驱动设计,它是对面向对象的的分析和设计(OOAD,Object Orient Analysis Design)的一个补充,对技术框架进行了分层规划,同时对每个类进行了策略和类型划分。领域模型是领域驱动的...

      DDD领域模型

      官方说法

      领域驱动设计,它是对面向对象的的分析和设计(OOAD,Object Orient Analysis Design)的一个补充,对技术框架进行了分层规划,同时对每个类进行了策略和类型划分。领域模型是领域驱动的核心 ,采用DDD的设计思想,业务逻辑不再集中在几个大型的类上,而是在大量相对小的领域对象上,这些类具有自己的状态和行为,每个类都是完成的独立的,并与现实领域的业务对象形成一种映射。基于DDD的架构设计,保证了系统的可维护性,扩展性和敏捷性,在处理复杂业务逻辑方面有着明显的优势!

      以上是官方的说法:http://www.jdon.com/ddd.html

      个人理解

      传统的软件生产过程:分析,设计,编程,测试,部署。然而在真实的环境中,分析和设计时分开的,分析人员不需要了解设计,只需要知道设计-实现难度即可,而设计人员在接到分析的需求后,并不能很好的理解需求。而DDD就是抛弃了这种做法,在分析阶段,就将设计加入其中,给分析人员提出了更高的要求。

      DDD的弊端也十分明显,如果需求出现大范围改动,整个模型可能不再适合,这个时候吗,需要重新设计模型。给后期的维护带来更大的麻烦。 这也是

      DDD革命性在于:领域模型准确反映了业务语言,而传统的分层架构只关心数据, 这些数据对象除了简单读、写操作外,没有任何业务方法,被比喻成失血模型,那么领域模型这种带有业务方法的充血模型到底好在哪里?

      看到领域模型代码,就看到业务需求,没有翻译没有转换,保证软件真正实现“拷贝不走样”。

      DDD最大的好处是:接触到需求第一步就是考虑领域模型,而不是将其切割成数据和行为,然后数据用数据库实现, 行为使用服务实现,最后造成需求的首肢分离。DDD让你首先考虑的是业务语言,而不是数据。重点不同导致编程世界观不同。

      DDD的特点

      分层架构

      成熟、清晰的分层架构。

      领域对象与世界的业务映射。

      明确的职责划分。

      复用性

      领域对象是核心

      领域对象完美的描述了业务。

      设计基于领域对象,而不是数据库。

      适用对象

      具备复杂的业务逻辑的如软件

      对设计和开发人员要较高

      不适用普通的CRUD操作

      系统维护性和扩展性高

      DDD 的分层

      一般的系统设计是,一般分为三层:数据层,业务层,表现层,即MVC模式。

      DDD分层的方式发生了变化分成了:表现层,应用层,领域层,基础层。

      表现层也就是view层,这个无论怎么设计都不会丢。

      应用层:用来协助应用活动,不包含业务逻辑,不保存对象,只保存任务状态,相当于一个任务流。

      领域层:包含领域信息,包含绝大部分的业务,保留业务对象的状态,需要将业务对象交给持久化处理。

      基础层:可以理解为持久化,

      DDD中的几个核心对象

      Entites:包含业务逻辑的实体(domain)

      Factories:工厂类,用来生成对象

      Respositories:持久化,本身就是DAO

      Service:服务层,为Controller提供接口,负责领域对象的再次封装和业务流处理。

      模型中的Model

      在DDD模型中,一般分为三种模型,ViewModel,DomainModel,Model。

      ViewModel与UI数据对应

      DomainMode与领域业务模型对应,与业务关联。

      Model实体模型,与数据表对应。

      失血、贫血、充血、胀血模型

      失血模型:只有getter/setter方法,没有任何业务逻辑,也不包含任何的实体关系。

      优点:思路清晰,编写代码方便,所有业务都在service中。

      缺点:service过重,业务中出现大概率重复调用的情况。

      贫血模型:在这里Entity应该叫domain。简单来说,就是除了getter/setter方法外,兼任了组装实体的业务,并且保留实体之间的关系,或者说是实体之前的嵌套。依然是service–DAO–domain(entity)的层级关系。

      优点:各层级单向依赖,结构清楚,很容易编写,也容易维护。稳定。

      缺点:domain部分流转被封到了Service层,不够面向对象。Service也比较厚重。

      充血对象:充血模型是将DAO也挪到domain中,由domain去持久化对象。调用关系变成了service–domain–DAO。

      优点:很面向对象。Service很薄,

      缺点:DAO和domain双向依赖,存在很多问题。划分domain和service业务混杂,不同人员有不同理解。Service也需要调用domain的业务方法,相当于又封装了业务。

      胀血对象:取消Service层,只保留domain–DAO。

      优点:简化分层

      缺点:业务暴露太多给Web层。service的业务也被强行加入了domain,可能引发domain不稳定。

      四种模型中,失血和胀血模型,不应该被提倡,因为弊大于利。而贫血,充血这两种在技术上已经很成熟了。但是推荐使用贫血模型。因为充血模型中,DAO和domain双向依赖带来结构问题。而且在批量操作domain的结构,很不合理。推荐使用贫血模型,增加少量的业务在entity中。比如参数构造,getter/setter中加入少量的逻辑判断。编码优先级最高的是完成业务的同时,引起的BUG更少。至于是不是面

    展开全文
  • 要想深入掌握和了解DDD 领域驱动设计的核心,那无论如何也绕不开两大较为抽象的概念——“贫血模型”、“充血模型”: 贫血模型即事务脚本模式。 充血模型即领域模型模式。 - 贫血模型 - 贫血...

    图片

    -     前言     -

     

    要想深入掌握和了解 DDD 领域驱动设计的核心,那无论如何也绕不开两大较为抽象的概念——“贫血模型”、“充血模型”:

     

    • 贫血模型即事务脚本模式。

    • 充血模型即领域模型模式。

     

    图片

    -     贫血模型     -

     

    贫血模型最早广泛应用源于EJB2,最强盛时期则是由Spring创造,将:

    • “行为”(逻辑、过程);

    • “状态”(数据,对应到语言就是对象成员变量)。

     

    分离到不同的对象中:

    • 只有状态的对象就是所谓的“贫血对象”(常称为VO——Value Object);

    • 只有行为的对象就是,我们常见的N层结构中的Logic/Service/Manager层(对应到EJB2中的Stateless Session Bean)。

     

    ——曾经Spring的作者Rod Johnson也承认,Spring不过是在沿袭EJB2时代的“事务脚本”,也就是面向过程编程。

     

    贫血领域模型是一个存在已久的反模式,目前仍有许多拥趸者。

     

    Martin Fowler 曾经和 Eric Evans 聊天谈到它时,都觉得这个模型似乎越来越流行了。作为领域模型的推广者,他们觉得这不是一件好事。

     

    图片

     

    贫血领域模型的基本特征是:它第一眼看起来还真像这么回事儿。项目中有许多对象,它们的命名都是根据领域来的。对象之间有着丰富的连接方式,和真正的领域模型非常相似。但当你检视这些对象的行为时,会发现它们基本上没有任何行为,仅仅是一堆getter/setter。

     

    其实,这些对象在设计之初就被定义为只能包含数据,不能加入领域逻辑;逻辑要全部写入一组叫Service的对象中;而Service则构建在领域模型之上,需要使用这些模型来传递数据。

     

    这种反模式的恐怖之处在于:它完全和面向对象设计背道而驰。面向对象设计主张将数据和行为绑定在一起,而贫血领域模型则更像是一种面向过程设计,Martin Fowler和Eric在Smalltalk时就极力反对这种做法。更糟糕的是,很多人认为这些贫血领域对象是真正的对象,从而彻底误解了面向对象设计的涵义。

     

    如今,面向对象的概念已经传播得很广泛了,而要反对这种贫血领域模型的做法,还需要更多论据。贫血领域模型的根本问题是,它引入了领域模型设计的所有成本,却没有带来任何好处。最主要的成本是将对象映射到数据库中,从而产生了一个O/R(对象关系)映射层。

     

    只有当你充分使用了面向对象设计来组织复杂的业务逻辑后,这一成本才能够被抵消。如果将所有行为都写入到Service对象,那最终你会得到一组事务处理脚本,从而错过了领域模型带来的好处。正如martin在企业应用架构模式一书中说到的,领域模型并不一定是最好的工具。

     

    将行为放入领域模型,这点和分层设计(领域层、持久化层、展现层等)并不冲突。因为领域模型中放入的是和领域相关的逻辑——验证、计算、业务规则等。如果你要讨论能否将数据源或展现逻辑放入到领域模型中,这就不在本文论述范围之内了。

     

    一些面向对象专家的观点有时会让人产生疑惑,他们认为的确应该有一个面向过程的服务层。但是,这并不意味着领域模型就不应该包含行为。事实上,service层需要和一组富含行为的领域模型结合使用。

     

    Eric Evans的Domain Driven Design一书中提到:

     

    应用层(即Service层)

    描述应用程序所要做的工作,并调度丰富的领域模型来完成它。这个层次的任务是描述业务逻辑,或和其它项目的应用层做交互。这层很薄,不包含任何业务规则或知识,仅用于调度和派发任务给下一层的领域模型。这层没有业务状态,但可以为用户或程序提供任务状态。

     

    领域层(或者叫模型层)

    表示业务逻辑、业务场景和规则。该层次会控制和使用业务状态,即使这些状态最终会交由持久化层来存储。总之,该层是软件核心。

     

    服务层很薄——所有重要的业务逻辑都写在领域层。他在服务模式中复述了这一观点:如今人们常犯的错误是不愿花时间将业务逻辑放到合适的领域模型中,从而逐渐形成面向过程的程序设计。

     

    我不清楚为什么这种反模式会那么常见。我怀疑是因为大多数人并没有使用过一个设计良好的领域模型,特别是那些以数据为中心的开发人员。此外,有些技术也会推动这种反模式,比如J2EE的Entity Bean,这会让我更倾向于使用POJO领域模型。

     

    总之,如果你将大部分行为都放置在服务层,那么你就会失去领域模型带来的好处。如果你将所有行为都放在服务层,那你就无可救药了。

     

    优点

    简单:

    • 对于只有少量业务逻辑的应用来说,使用起来非常自然;

    • 开发迅速,易于理解;

    • 注意:也不能完全排斥这种方式。

     

    缺点

    无法良好的应对复杂逻辑:

    • 比如收入确认规则发生变化,例如在4月1号之前签订的合同要使用某规则……

    • 和欧洲签订的合同使用另外一个规则……

     

     

    图片

    -     充血模型     -

     

    面向对象设计的本质是:“一个对象是拥有状态和行为的”。

     

    比如一个人:

    • 他眼睛什么样鼻子什么样这就是状态;

    • 人可以去打游戏或是写程序,这就是行为。

     

    为什么要有一个“人Manager”这样的东西存在去帮人“打游戏”呢?举个简单的J2EE案例,设计一个与用户(User)相关功能。

     

    传统的设计一般是:

    • 类:User+UserManager;

    • 保存用户调用:userManager.save(User user)。

     

    充血的设计则可能会是:

    • 类:User;

    • 保存用户调用:user.save();

    • User有一个行为是:保存它自己。

     

    其实它们没有什么特别适用的方向,个人更倾向于总是使用充血模型,因为OOP总是比面向过程编程要有更丰富的语义、更合理的组织、更强的可维护性—当然也更难掌握。

     

    因此实际工程场景中,是否使用,如何使用还依赖于设计者以及团队充血模型设计的理解和把握,因为现在绝大多数J2EE开发者都受贫血模型影响非常深。另外,实际工程场景中使用充血模型,还会碰到很多很多细节问题,其中最大的难关就是“如何设计充血模型”或者说“如何从复杂的业务中分离出恰到好处且包含语义的逻辑放到VO的行为中”。

     

    如果一个对象包含其他对象,那就将职责继续委托下去,由具体的 POJO 执行业务逻辑,将策略模式更加细粒度,而不是写 ifelse。

    展开全文
  • 和贫血模型对应的就是充血模型。 什么是充血模型充血模型就是不缺血了,有数据同样有业务逻辑。 比如你的计算类现在不只有加法计算,还有需要的数据。 我们现在进行的开发基本上都是基于贫血模型开发的。 比如一...
  • DDD工程项目结构(充血模型

    千次阅读 2020-05-08 17:27:12
    本篇文章将展示如何在DDD的思想之下建立自己的工程项目结构,并且这里我们使用充血模型DDD将我们的工程结构分为接口层、领域层、应用层、基础层。各层之间都为单向调用,并且不可跨层进行调用,除了基础层的三方...
  • 最近公司开始推行DDD(领域驱动设计),基于充血模型的面向对象开发模式是DDD的特点之一,而在平时开发中我们都使用的是MVC 架构是基于贫血模型的面向过程开发风格,也许有同学就会问了,贫血模型和充血模型是的什么...
  • DDD项目架构与充血模型实例

    千次阅读 2020-10-05 18:28:00
    1 DDD 最近一段时间在学习领域驱动设计,同时也学习了COLA代码并进行了一些项目实践,COLA代码整洁优雅,但有一定学习成本和使用成本。最终一个工程思想还是要落地,我综合了一些DDD技术框架,删除了CQRS和事件总线...
  • 贫血模型即是事务脚本模式,充血模型即是领域模型模式。 贫血模型 最早广泛应用是源自于EJB2,最强盛时期则是由Spring创造,把“行为”(也称为逻辑、过程)和“状态”(可理解为数据,对应到语言就是对象成员变量)...
  • 什么是失血模型和充血模型? 如题,那么什么是失血模型(贫血模型)呢? 我们在日常开发中,经常会需要用到各种model,定义各种 DTO/VO/BO/PO 等数据载体, 那么我们细想一下,对于这种实体,我们通常对它的...
  • 点击下方“IT牧场”,选择“设为星标”- 前言 -要想深入掌握和了解 DDD 领域驱动设计的核心,那无论如何也绕不开两大较为抽象的概念——“贫血模型”、“充血模型”:贫血模...
  • DDD(领取驱动设计)系列主题之失血模型,贫血模型与充血模型
  • 我觉得DDD开发模式就是把部分需要操作的通用的操作实体类的代码,从service层转入domain层,使得让后面的人阅读代码起来可以更加专注在业务上。 比如说一个通用的逻辑删除(目前我们库里是有个enable字段的,enable...
  • 1 DDD 最近在学习领域驱动设计,同时也学习了COLA代码并进行了一些项目实践,COLA代码整洁优雅,但有一定学习成本和使用成本。最终一个工程思想还是要落地,我综合了一些DDD技术框架,删除了CQRS和事件总线模式,...
  • 3.1 基于贫血模型的传统开发模式 // BO,不包含业务逻辑爱 public class VirtualWalletBo { // 省略 getter/setter/constructor 方法 private Long id; private Long createTime; private BigDecimal balance...
  • 点击上方蓝色“石杉的架构笔记”,选择“设为星标” 回复“PDF”获取独家整理的学习资料! 长按扫描上方免费领取前言要想深入掌握和了解DDD 领域驱动设计的核心,那无论如何也绕不...
  • 充血模型 vs 贫血模型

    2018-11-26 14:00:41
    DDD 战术模型之后,看到第一篇关于聚合设计 Chat 的童鞋们,应该会有很多疑惑,那么这本 Chat 将为大家解决以下疑惑,我们的业务模型设计为什么要才用 DDD 的设计原则? 什么样的业务场景适合采用 DDD? DDD 解决了...
  • 设计模式之美 - 12 | 实战一(下):如何利用基于充血模型DDD开发一个虚拟钱包系统?钱包业务背景介绍钱包系统的设计思路基于贫血模型的传统开发模式基于充血模型DDD 开发模式辩证思考与灵活应用重点回顾课堂...
  • 基于目前的理解来说,简单解释一下贫血模型与充血模型 贫血模型 仅有一些属性与get、set方法,大致可以理解为这是个不完整的对象,仅具有对象的属性,并不具有一些动作 举个例子来说,在传统MVC框架中的DO类,...

空空如也

空空如也

1 2 3 4 5 6
收藏数 111
精华内容 44
关键字:

ddd充血模型