贫血模型是指领域对象里只有 get 和 set 方法（POJO），所有的业务逻辑都不包含在内而是放在 Business Logic 层。...在使用 Spring 的时候，通常暗示着你使用了贫血模型，我们把 Domain 类用来单纯地存储数据，Spring 管不着这些类的注入和管理，Spring 关心的逻辑层（比如单例的被池化了的 Business...贫血模型实施的最大难度在于如何梳理好 Business Logic 层内部的划分关系，由于该层会比较庞大，边界不易控制，内部的各个模块之间的依赖关系不易管理，可以考虑这样这样的实现思路： （1）铺设扁平的原子业务逻辑层...它的优点是面向对象，Business Logic 符合单一职责，不像在贫血模型里面那样包含所有的业务逻辑太过沉重。...使用 RoR 开发时， 每一个领域模型对象都可以具备自己的基础业务方法，通常满足充血模型的特征。充血模型更加适合较复杂业务逻辑的设计开发。
前言 要想深入掌握和了解 DDD 领域驱动设计的核心，那无论如何也绕不开两大较为抽象的概念——“贫血模型”、“充血模型”： 贫血模型即事务脚本模式。 充血模型即领域模型模式。...| 贫血模型 贫血模型最早广泛应用源于EJB2，最强盛时期则是由Spring创造，将： “行为”（逻辑、过程）； “状态”（数据，对应到语言就是对象成员变量）。...作为领域模型的推广者，他们觉得这不是一件好事。 贫血领域模型的基本特征是：它第一眼看起来还真像这么回事儿。项目中有许多对象，它们的命名都是根据领域来的。...更糟糕的是，很多人认为这些贫血领域对象是真正的对象，从而彻底误解了面向对象设计的涵义。 如今，面向对象的概念已经传播得很广泛了，而要反对这种贫血领域模型的做法，还需要更多论据。...因此实际工程场景中，是否使用，如何使用还依赖于设计者以及团队充血模型设计的理解和把握，因为现在绝大多数J2EE开发者都受贫血模型影响非常深。
贫血模型即事务脚本模式 充血模型即领域模型模式 贫血模型 最早广泛应用源于EJB2，最强盛时期则是由Spring创造，把 “行为”（逻辑、过程） “状态”（数据，对应到语言就是对象成员变量） 分离到不同的对象中...贫血领域模型的基本特征是：它第一眼看起来还真像这么回事儿。项目中有许多对象，它们的命名都是根据领域来的。对象之间有着丰富的连接方式，和真正的领域模型非常相似。...更糟糕的时，很多人认为这些贫血领域对象是真正的对象，从而彻底误解了面向对象设计的涵义。 如今，面向对象的概念已经传播得很广泛了，而要反对这种贫血领域模型的做法，还需要更多论据。...贫血领域模型的根本问题在于，它引入了领域模型设计的所有成本，却没有带来任何好处。 最主要的成本是将对象映射到数据库中，从而产生了一个O/R（对象关系）映射层。...因此实际工程场景中，是否使用，如何使用还依赖于设计者以及团队充血模型设计的理解和把握，因为现在绝大多数J2EE开发者都受贫血模型影响非常深。
以前就听别人说过这俩种模型。...它们描述的对象是面向对象设计中的实体，构建领域模型(Domain model)时，贫血模型与充血模型给出了俩种不同的方案： 贫血模型：是指领域对象里只有get和set方法，或者包含少量的其它方法，与之有关的业务逻辑都不放在该类中...充血模型：充血模型与之不同，不仅有get/set方法，还有业务逻辑也在领域模型(Domain model)里面，Business Logic只是简单封装部分业务逻辑以及控制流程。...贫血模型的好处： 每个贫血对象职责单一(体现在哪：每个对象几乎只有属性，get/set方法，无业务逻辑)，这样模块间、对象间解耦程度很高。...贫血模型的坏处： 对象状态和行为分离(贫血模型中，对象只有属性，get/set方法，业务逻辑在不在对象类内部)，所以一个完整的业务逻辑描述不能在一个类中完成，而是一组相互协作的类共同完成的。
- 前言 - 要想深入掌握和了解 DDD 领域驱动设计的核心，那无论如何也绕不开两大较为抽象的概念——“贫血模型”、“充血模型”： 贫血模型即事务脚本模式。 充血模型即领域模型模式。...- 贫血模型 - 贫血模型最早广泛应用源于EJB2，最强盛时期则是由Spring创造，将： “行为”（逻辑、过程）； “状态”（数据，对应到语言就是对象成员变量）。...作为领域模型的推广者，他们觉得这不是一件好事。 贫血领域模型的基本特征是：它第一眼看起来还真像这么回事儿。项目中有许多对象，它们的命名都是根据领域来的。...更糟糕的是，很多人认为这些贫血领域对象是真正的对象，从而彻底误解了面向对象设计的涵义。 如今，面向对象的概念已经传播得很广泛了，而要反对这种贫血领域模型的做法，还需要更多论据。...因此实际工程场景中，是否使用，如何使用还依赖于设计者以及团队充血模型设计的理解和把握，因为现在绝大多数J2EE开发者都受贫血模型影响非常深。
今天跟大家分享一个知识点即领域模型之 贫血模型和充血模型。 看完这篇文章你会更深入理解各自的优缺点和适用场景。希望对你平时开发和架构设计有所参考和帮助。...贫血模型 1 什么是贫血模型 贫血模型是一种领域模型，该模型下的领域对象包含很少或没有业务逻辑(对象只包含基本的属性即属性对应的getter/setter方法）。...上面的介绍可能稍微觉得抽象，我觉得要理解贫血模型我们要了解另一个知识点即事务脚本编程模式。...业界也叫贫血模式。...通过领域模型对象的交互，完成业务逻辑的实现。可以这么说设计好了领域对象，也就设计好了业务逻辑实现。 所以业界又把这种模型称为领域模型。 它是真正的遵守面向对象编程思想，体现高内聚，低耦合理念！
考虑到你有可能不太了解我刚刚提到的这几个概念，所以，在正式进入实战项目的讲解之前，我先带你搞清楚下面几个问题： 什么是贫血模型？什么是充血模型？ 为什么说基于贫血模型的传统开发模式违反 OOP?...现在，我们再来看一下，什么是贫血模型？ 实际上，你可能一直都在用贫血模型做开发，只是自己不知道而已。不夸张地讲，据我了解，目前几乎所有的业务后端系统，都是基于贫血模型的。...这种贫血模型将数据与操作分离，破坏了面向对象的封装特性，是一种典型的面向过程的编程风格。 什么是基于充血模型的 DDD 开发模式？ 刚刚我们讲了基于贫血模型的传统的开发模式。...为什么基于贫血模型的传统开发模式如此受欢迎？ 前面我们讲过，基于贫血模型的传统开发模式，将数据与业务逻辑分离，违反了 OOP的封装特性，实际上是一种面向过程的编程风格。...既然基于贫血模型的开发模式已经成为了一种约定俗成的开发习惯，那什么样的项目应该考虑使用基于充血模型的 DDD 开发模式呢？ 刚刚我们讲到，基于贫血模型的传统的开发模式，比较适合业务比较简单的系统开发。
背景 最近公司开始推行DDD（领域驱动设计），基于充血模型的面向对象开发模式是DDD的特点之一，而在平时开发中我们都使用的是MVC 架构是基于贫血模型的面向过程开发风格，也许有同学就会问了，贫血模型和充血模型是的什么呢...贫血模型和充血模型 简介 贫血模型： 定义对象的简单的属性值，没有业务逻辑上的方法（个人理解）没有找到官方解释 充血模型 充血模型也就是我们在定义属性的同时也会定义方法，我们的属性是可以通过某些方式直接得到属性值...回归正题还是看充血模型和贫血模型 说了这么多DDD思想中的充血模型到底优势在哪里呢？适用于哪些场景呢？而我们都在用贫血模型，但是我们在平时的开发中也没有什么问题呀？ 为什么大家都在使用贫血模型？...综上所述： 充血模型的设计要比贫血模型更加有难度 大家一致使用基于贫血模型的面向过程编程已经成为习惯，比较难转换思想 还有就是对代码不负责任的态度。...总结 贫血模型和充血模型的简单解释 以及DDD开发模式和面向过程编程与充血和贫血模型的关系 对比了基于贫血模型的MVC层的面向过程编程范式和基于充血模型的面向对象编程范式的对比 两种模型分别适用于那种场景
在《领域驱动设计》这本书里面，列举了三种可将业务逻辑建模为软件模型的模式，也就是大家常听说的事务脚本、贫血模型、DDD。有好些名字来描述这三种模式。...贫血模型 Anemic Model 贫血模型似乎从摒弃存储过程之后，把存储过程的搬迁到service中，实体对象与表一一对应。也被称为Table Module,表模块。...到此，我们就明白了为什么贫血模型的火热原因。 而且，正因为有这种局限性，当我们想去构建OO充血模型时，这种分裂阻碍了我们。...为系统提供一个统一门面，至于系统内部是用贫血模型，还是贫血模型，对外部来讲是个黑盒，客户端不用关心。 那么再放大点，现在微服务架构是标配，我们只要知道服务在哪儿，提供了什么能力。...经过这几种风格对比，随着AI的兴起，还会再出现新的模型方法，将来OO还是追求的最优解吗？ 总结 实现业务架构的三种方式，贫血模型随处可见，而事务脚本与充血模型倒却难得一见。
本篇文章将先探讨贫血模型的问题，再去探究在EF Core中使用Code First时如何使用简单的方法来避免贫血模型。...2.什么是贫血模型 在对领域建模后，输出一系列类中仅包含一些简单属性声明而不包含业务逻辑的模型，就属于贫血模型。...贫血模型是十分常见的。从我的经验来看，EF中超过80%的领域模型都是贫血模型。这并不奇怪。几乎所有的文档和其他博客文章都以最简单的方式展示了EF。他们专注于尽可能快地开始工作，而不是主张最佳实践。...3.改造为更丰富的领域模型（充血模型） 下面我们将讨论三种简单的方式去丰富你的贫血模型。这几种方法都非常简单，仅需要最小的改动。...温馨提示 当您打算从贫血域模型转移到更丰富的领域模型时，您将立即体会到将领域级的业务逻辑封装在领域对象中的好处。请注意，尽管如此，尝试并不是件容易的事。
下载数据集请登录爱数科(www.idatascience.cn) 贫血是一种红血球或血红蛋白浓度低于正常值的疾病。贫血会产生疲劳、虚弱、头晕和呼吸急促等症状。...满足生理需要所需的最佳血红蛋白浓度因年龄、性别、居住海拔、吸烟习惯和怀孕状况而异，本数据集包含了世界范围内内的贫血儿童数据。 1. 字段描述 2. 数据预览 3. 字段诊断信息 4.
丰色 发自 凹非寺 量子位 报道 | 公众号 QbitAI 不用扎针、不用让本就贫血的人“雪上加霜”—— 用手机拍照就可以检测一个人是否贫血，不知道你听说过没？...Q：首先你知道为什么可以通过拍照识别贫血吗？ A：因为贫血患者的肤色和正常人是不太一样的。 Q：那为什么非要拍下眼睛呢？ A：说来还长…… 长话短说！...ps.女性<12.5 g/dL、男性<13.5 g/dL为贫血 首先，对第一期原来的142名患者的测试发现，预测模型通过结膜估计的血红蛋白值（HBc）与实验室抽血值（HBl）的相关性图显示：斜率=1.07...因此他们对模型进行了多次改进迭代，包括取两眼的平均值进行预测、不采用闪光灯拍摄等。...研究人员表示： 基于目前的实验数据，该模型可以先用作贫血的筛查工具，一旦检测出任何异常结果再进行确认检测。
什么是基于贫血模型的传统开发模式？...这种贫血模型将数据与操作分离，破坏了面向对象的封装特性，是一种典型的面向过程的编程风格。 什么是基于充血模型的 DDD 开发模式？...基于贫血模型的传统的开发模式，重 Service 轻 BO；基于充血模型的 DDD 开发模式，轻 Service 重 Domain。 为什么基于贫血模型的传统开发模式如此受欢迎？...相对于原来的贫血模型的设计思路，这种充血模型的设计思路，貌似并没有太大优势。这也是大部分业务系统都使用基于贫血模型开发的原因。...小结 基于充血模型的 DDD 开发模式跟基于贫血模型的传统开发模式相比，主要区别在 Service 层。
贫血模型 贫血模型准确地说，应该被称之为“贫血领域模型（Anemic Domain Model）”，因为这个术语其实是在领域模型这个语境中使用的。...当我们在讨论领域模型时，发现更有好事者在贫血模型的基础上衍生出各种与“血”有关的各种模型，统计下来，除了Martin Fowler提出的贫血模型之外，还包括失血模型、充血模型与胀血模型。...我还看到有的人错误的理解或者误用了“贫血模型”的定义，将只有字段和字段的getter/setter方法的类称之为“失血模型”，而将Martin Fowler提出的富领域模型称之为“贫血模型”。...顾名思义，贫血（Anemic）这个词代表着不健康，贫血模型当然就意指不健康的模型。...如果采用这篇文章的定义，Martin Fowler所推崇的富领域模型反倒成了不健康的贫血模型（虽然该文作者未必认为贫血模型不健康），该何其无辜啊！
日拱一卒 | 设计模式之美 | 03 面向对象 实战篇 日拱一卒（3/100） 今天学习分享的是王争的《设计模式之美》之《面向对象》实战篇 基于贫血模型的 MVC 架构 什么是贫血模型？...系统业务简单，贫血模型足以应付。 充血模型设计更加有难度。 学习成本、转型成本。 基于充血模型的 DDD 模式 什么是充血模型？...与贫血模型相反，数据和对应的业务逻辑封装在一个类中，就是充血模型（Rich Domain Model）。 什么是领域驱动设计？...基于贫血模型：重 Service 轻 BO； 基于充血模型：轻 Service 重 Domain。...对于业务不复杂的系统开发来说，基于贫血模型的传统开发模式简单够用，基于充血模型的 DDD 开发模式有点大材小用，无法发挥作用。
一个并没有行业经验积累的软件公司，它开发的软件，基本上完全是需求驱动，而不是领域模型驱动。只有具备了领域模型积累的公司才有资格去谈领域模型驱动软件开发。...但是我们应该看到，Martin批评的贫血的领域模型并不是Hibernate实体类，Martin指的贫血的领域模型实际上是缺乏丰富业务逻辑概念的领域抽象模型，这和Hibernate实体类完全是风牛马不相及的东西...我认为，Martin批评的贫血的领域模型是指只关注了领域模型持久化特征方面，而忽略了领域模型其他特征方面的模型，这样的模型是贫血的。...因为这种模型只关注了模型在技术层面的外在表现，也就是说只关注了数据的存取操作，而忽视了模型蕴含的业务核心价值。 举例来说，我们编一个银行软件，如果你只关注了账户的增删改查，这叫做贫血！...由这些POJO的类互相协作来共同完成这个领域模型。如果你仅仅关注Account的增删改查，那就贫血了，而如果你关注了账户的业务规则，并且考虑一组互相协作的类去完成它，就不是贫血的。
程序员开发生涯是从学习J2EE经典的分层理论开始的（Action、Service、Dao），在这种分层理论中，我们基本没有啥机会使用那些所谓的“行为型”的设计模式，这里的核心原因，就是J2EE经典分层的开发方式是“贫血模型...Martin Fowler在他的《企业应用架构模式》这本书中提出了两种开发方式“事务脚本”和“领域模型”，这两种开发分别对应了“贫血模型”和“充血模型”。...使用这种开发方式，对象只用于在各层之间传输数据用，这里的对象就是“贫血模型”，只有数据字段和Get/Set方法，没有逻辑在对象中。...马丁福勒定义的“贫血模型”是反模式，面对简单的小系统用事务脚本方式开发没问题，业务逻辑复杂了，业务逻辑、各种状态散布在大量的函数中，维护扩展的成本一下子就上来，贫血模型没有实施微服务的基础。...贫血模型完全依靠数据库对并发的支撑，实现可以简化很多，但充血模型就得自己实现了，不管是在内存中通过锁对象，还是使用Redis的远程锁机制，都比贫血模型复杂而且可靠性下降，这是充血模型带来的挑战。
在二次创业中，要弄清这个业务能力，还是让我们先从贫血模型和充血模型说起。...充血模型是领域模型模式，实现起来就相对”复杂”些，那么我觉得这种复杂也是相对贫血模型的脚本式编程来说的。...充血模型真的那么”复杂“，贫血模型真的那么”简单“吗？...你仔细回忆一下，贫血模型的代码结构，Service类，Person类，使用它们的Client类，一个也不少，而且这段结构最终的样子就是下面这样。...贫血领域模型的根本问题是，它引入了领域模型设计的所有成本，却没有带来任何好处。 只有当你充分使用了面向对象设计来组织复杂的业务逻辑后，这一成本才能够被抵消。
什么是领域模型？ • 领域模型是关于某个特定业务领域的软件模型。通常，领域模型通过对象模型来实现（对象=数据+行为），并且表达了准确的业务含义。 贫血领域模型 什么是贫血领域对象？...贫血领域对象怎么了？ 贫血领域对象是不好的，因为它根本就不是领域对象，而只是将关系型数据库中的模型映射到了对象上而已。 最初是在窗口设计领域上，将getter和setter变得过于流行了。...由于贫血模型不包含领域相关业务逻辑，所以通过贫血模型，我们根本无法解答上面的问题。...改造贫血领域模型 通过上面的学习，我们已经掌握了DDD的很多知识，并且也拥有了通用语言这把武器。...在上面我们看到了一个saveCustomer方法所涉及的贫血模型，下面我们利用自己掌握的DDD相关知识，对它进行一个小改造。
的实现案例可以参考下面这篇文章： “【领域驱动设计在互联网业务开发中的实践】 https://tech.meituan.com/2017/12/22/ddd-in-practice.html ” 关于DDD你需要知道的 贫血模型...“贫血领域对象 贫血领域对象（Anemic Domain Object）是指仅用作数据载体，而没有行为和动作的领域对象。...既然有贫血领域对象，那也就有充血领域对象。 “充血领域对象 实体除了Getter/Setter方法，还有描述实体行为和动作的方法 ” 我们举个例子，这里有一个订单实体Order。...上面实体并没有描述实体行为的方法，所以该实体是贫血模型。 如果我们需要一个专门修改订单为发货的方法，可以这样写 如果用充血模型写是什么样子的呢？...其实按通常思路来说贫血模型没毛病，但是当业务逻辑复杂了，业务逻辑，状态会散落在大量的方法中，原本代码的意图会渐渐不明确。
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
即时通信 IM
ICP备案
对象存储
实时音视频
