用这么麻烦吗？

起因

昨天群里讨论

@北京-sky 群主大大，有个问题请教一下，现在项目里看到的分层结构，基本就是controller、service、dao、entity，而service层都很薄，基本就是直接调用dao对表数据进行操作，几乎看不到面向对象设计里面的继承关系、聚合组合关系；那新做一个项目的话，到底怎么去分层，怎么搭建面向对象的开发框架

这个不用重复造轮子 单体项目里边搞不出什么花样

灰灰熊 2020/7/6 星期一 11:26:19 分层本身我觉得没有问题，关键是service层和entity层到底怎么定义？ 领域模型又可以分为失血、贫血和充血3种。 失血模型：基于数据库的领域设计方式就是典型的失血模型，只关注数据的增删改查。 贫血模型：就是在domain object包含了不依赖于持久化的领域逻辑，而那些依赖持久化的领域逻辑被分离到server层。 充血模型：充血模型跟贫血模型差不多，不同的是如何划分业务逻辑，就是说，约大部分业务应该放到domain object里面，而service应该是很薄的一层。 到底用充血模型还是贫血模型比较好

业务要持续扩展，会越来越大 根据业务拆分啊

拆分肯定是要做的

先规划好 多一些设计时间

现在的问题是，面向对象设计和数据库表结构的设计是有差别的，使用orm可以将表结构转换成业务实体对象，但是业务实体行为是要与业务实体对象拆分开来放在不同层吗？

这个看你设计的架构吧 哪种更方便你的业务 扩展行更强

如果业务实体行为与业务实体对象不进行拆分的话，应该是把它们放在service层呢还是放在entity层呢？正常情况下实体就是对象，业务层负责业务逻辑

看来还是不折腾了

领域模型

理论派观点

•Domain Model是一个商业建模范畴概念，即使一个企业不开发软件，也具备其业务模型；•所有同行企业，其业务模型必定有非常大的共性和内在的规律性。•由行业内的各个企业的业务模型再向上抽象出整个行业的业务模型，这个模型称之为“领域模型”。

实战派观点

领域模型是一个分析模型，帮助系统分析人员、用户认识现实业务的工具，描述的是业务中涉及到的实体及其相互之间的关系，它是需求分析的产物，与问题域相关。是需求分析人员与用户交流的有力工具，是彼此交流的语言。

常见的三层结构

•Web层（俗称展现层吧，Presentation Layer)：接收用户输入，将数据传至服务层；•服务层(Service Layer，可以叫Business Logic Layer)：事务边界，处理业务逻辑、权限管理与授权，并与存储层通信；•存储层（Data access layer）：与数据库进行通信，对数据进行持久化。

但是发现什么没有？问题出在了服务层，他承受了太多的职责，像事务管理、业务逻辑、权限检查等等，这违反了单一职责原则和关注分离原则，并且产生了大量的依赖和循环依赖。当业务复杂度上升时，服务层所包含的代码将会非常庞大和复杂，直接导致了测试成本的上升。这里正好有个例子，在现在的项目中，负责处理保险业务单的核心类中，包含了4000多行代码，它与数据库中某一关键表相关联，引用（注入）了十几个DAO。在数十个各类方法中，可以处理保单、再保、理赔等等各种不同的业务，同时它还深度依赖于hibernate，不但使用了ORM方法处理数据，甚至还直接用了HQL来获取数据。因为有众多其他服务类与他进行循环引用，项目后期这个庞然大物已经没有人敢轻易改动了，因为谁也不知道他到底都能做什么，重构更是不可能的事。

贫血、失血和充血模型

•失血模型：模型仅仅包含数据的定义和getter/setter方法，业务逻辑和应用逻辑都放到服务层中。这种类在java中叫POJO，在.NET中叫POCO。•贫血模型：贫血模型中包含了一些业务逻辑，但不包含依赖持久层的业务逻辑。这部分依赖于持久层的业务逻辑将会放到服务层中。可以看出，贫血模型中的领域对象是不依赖于持久层的。•充血模型：充血模型中包含了所有的业务逻辑，包括依赖于持久层的业务逻辑。所以，使用充血模型的领域层是依赖于持久层，简单表示就是UI层->服务层->领域层<->持久层•胀血模型：胀血模型就是把和业务逻辑不想关的其他应用逻辑（如授权、事务等）都放到领域模型中。我感觉胀血模型反而是另外一种的失血模型，因为服务层消失了，领域层干了服务层的事，到头来还是什么都没变。

从众心理

从众心理（conformity），指个人受到外界人群行为的影响，而在自己的知觉、判断、认识上表现出符合于公众舆论或多数人的行为方式。实验表明只有小部分人能够保持独立性，不被从众，因此从众心理是部分个体普遍所有的心理现象。

如果你只是个普通人，那就随波逐流吧，别去彰显自己的个性，别去反对大部分人都做错的事情。