关注Java核心技术,推送更多 Java 干货!
来源:juejin.cn/post/6917125801460629518
前言
要想深入掌握和了解 DDD 领域驱动设计的核心,那无论如何也绕不开两大较为抽象的概念——“贫血模型”、“充血模型”:
贫血模型
贫血模型最早广泛应用源于EJB2,最强盛时期则是由Spring创造,将:
——曾经Spring的作者Rod Johnson也承认,Spring不过是在沿袭EJB2时代的“事务脚本”,也就是面向过程编程。
Martin Fowler 曾经和 Eric Evans 聊天谈到它时,都觉得这个模型似乎越来越流行了。作为领域模型的推广者,他们觉得这不是一件好事。
其实,这些对象在设计之初就被定义为只能包含数据,不能加入领域逻辑;逻辑要全部写入一组叫Service的对象中;而Service则构建在领域模型之上,需要使用这些模型来传递数据。
一些面向对象专家的观点有时会让人产生疑惑,他们认为的确应该有一个面向过程的服务层。但是,这并不意味着领域模型就不应该包含行为。事实上,service层需要和一组富含行为的领域模型结合使用。最新 Java 面试题出炉!分享给你。
Eric Evans的Domain Driven Design一书中提到:
应用层(即Service层)
描述应用程序所要做的工作,并调度丰富的领域模型来完成它。这个层次的任务是描述业务逻辑,或和其它项目的应用层做交互。这层很薄,不包含任何业务规则或知识,仅用于调度和派发任务给下一层的领域模型。这层没有业务状态,但可以为用户或程序提供任务状态。
领域层(或者叫模型层)
表示业务逻辑、业务场景和规则。该层次会控制和使用业务状态,即使这些状态最终会交由持久化层来存储。总之,该层是软件核心。
服务层很薄——所有重要的业务逻辑都写在领域层。他在服务模式中复述了这一观点:如今人们常犯的错误是不愿花时间将业务逻辑放到合适的领域模型中,从而逐渐形成面向过程的程序设计。
我不清楚为什么这种反模式会那么常见。我怀疑是因为大多数人并没有使用过一个设计良好的领域模型,特别是那些以数据为中心的开发人员。此外,有些技术也会推动这种反模式,比如J2EE的Entity Bean,这会让我更倾向于使用POJO领域模型。
总之,如果你将大部分行为都放置在服务层,那么你就会失去领域模型带来的好处。如果你将所有行为都放在服务层,那你就无可救药了。
关注Java核心技术,推送更多 Java 干货!
优点
简单:
缺点
无法良好的应对复杂逻辑:
充血模型
面向对象设计的本质是:“一个对象是拥有状态和行为的”。
比如一个人:
为什么要有一个“人Manager”这样的东西存在去帮人“打游戏”呢?举个简单的J2EE案例,设计一个与用户(User)相关功能。最新 Java 面试题出炉!分享给你。
传统的设计一般是:
充血的设计则可能会是:
其实它们没有什么特别适用的方向,个人更倾向于总是使用充血模型,因为OOP总是比面向过程编程要有更丰富的语义、更合理的组织、更强的可维护性—当然也更难掌握。
因此实际工程场景中,是否使用,如何使用还依赖于设计者以及团队充血模型设计的理解和把握,因为现在绝大多数J2EE开发者都受贫血模型影响非常深。另外,实际工程场景中使用充血模型,还会碰到很多很多细节问题,其中最大的难关就是“如何设计充血模型”或者说“如何从复杂的业务中分离出恰到好处且包含语义的逻辑放到VO的行为中”。
如果一个对象包含其他对象,那就将职责继续委托下去,由具体的 POJO 执行业务逻辑,将策略模式更加细粒度,而不是写 ifelse。
2. 重磅!Oracle 宣布从 JDK 17 开始正式免费。。 3. Java 调用第三方接口,实战来了! 4. 用好这个IDEA插件,写代码效率至少提升5倍!
5. 手写一个迷你版 HashMap,面试随便问!
一个分享Java核心技术干货的公众号