Java程序员对领域驱动设计的思考与认知( 二 ) _Java程序员

前面我们说贫血模型实体类只有SET GET方法，逻辑基本在服务层实现。而充血模型它的实体类里不但有状态，还有行为，即属性和方法都有。它的Service层很薄。显然这不符合MVC的思想,因为充血模型中model中不仅有数据,还有状态。维护起来非常麻烦。
5. 领域驱动总结
针对贫血模型的service层非常复杂臃肿的缺点,领域模型的概念越来越流行起来,至少在一些很多的大公司中,非常盛行。领域模型的概念不仅可以重新去设计service,同时也在微服务设计中有重要的意义。所以说领域模型其实就是要解决service越来越臃肿的一种设计思想。主要就是对service中的复杂的业务逻辑进行拆分,根据领域来进行拆分。用面向对象的思想去重新设计service 。有人给他起了一个高大上的词汇: 领域模型。
所以最后小编想用一大白话来总结一下领域模型。
领域模型就是要用面向对象的思想去重新设计充斥着复杂业务逻辑的service层。
二、为什么要进行领域模型设计?相信看到这里的你,一定对领域模型有一个自己的认识。为什么要进行领域模型设计? 相信自己心里一定有一个自己的判断了。贫血模型的项目结构, service层无可避免的非常的臃肿，臃肿到一个方法可能深不见底。对于业务老油条，可能还凑合能看成，
假如你是一个新的同学,当你看到这样的代码一定是崩溃的，假如说注释也没有,那你内心更是崩溃的。假如说这是一个很庞大的系统,很复杂的业务流程,这就更不用说了。

文章插图

如果读到这里,你还是对领域驱动设计感到迷茫，那么就其实这个标题也可以这样讲: 我们如何对臃肿的service进行面向对象的设计。设计的过程就是对service层的代码进行领域设计。
而我们之所以这样做的目的。

为了快乐的coding
为了业务系统的稳定
为了业务更快的迭代升级。

当然这一切的前提是你对业务有一个全局的认识,有一个前瞻性的判断,否则也设计不出来,真正适合自身系统的领域驱动模型。
三、领域驱动的项目结构是什么样的?一千个人眼里有一千个哈姆雷特,没有最好的项目结构,只有最适合自己的业务系统。本文只是小编对领域驱动的模块的思考和认识。
仅供参考,希望对你有所启示和引导。
1. 领域划分|模块化建造

文章插图

领域划分,小编感觉用另外一个词形容也非常的合适,就是业务模块化。所有能力都进行能力化抽象,形成模块,形成领域。当遇到新的业务逻辑,底层的数据结构和数据关系肯定也是一样的。那么就可以像堆积木一样,根据这些模块快速的组装成新的业务逻辑。快速的实现业务的迭代和升级。
关于这个问题,需要结合自己的业务系统来进行抽象和设计。而小编的能做的就是,提醒你模块化设计,领域化设计的重要意义。
2. 项目结构
基础层(外部调用,db操作) + 领域层(偏向领域的业务逻辑) + 业务层(对领域层的业务编排) + 外观层(可以提供能力,可以提供视图) 。
有一个完善的领域层,可以方便快速便捷的对业务进行扩展。

文章插图

领域层就是模块化设计的积木。丰富的模块化有助于业务扩展。
一定要控制项目的依赖情况。service只能出现领域层的依赖, 领域层只能存在dao层和第三方服务层。各个层代码不能平行调用。

文章插图

3. 编程规范
关于项目提出6个注意的点。如果把做项目比作是前线打仗,那么打仗最重要的是战斗成员目标要一致。在目标不一致的情况下一定要进行充分讨论(项目负责人要做的),说明情况互相妥协指定出统一的项目编程规范。去进行执行。一旦指定不能违背。否则项目质量不保。
项目固然重要,但是作为软件开发工程师,首先要对代码质量做保障。