微服务体系的分层设计和领域划分 一层一模型 应用层、领域层人员分工

小结：

1、

“一层一模型”本质是解耦模型依赖。

 

Java生鲜电商平台-SpringCloud微服务架构中核心要点和实现原理 - 巨人大哥 - 博客园 https://www.cnblogs.com/jurendage/p/11364846.html

Java生鲜电商平台-生鲜电商中微服务体系中的分层设计和领域划分？(小程序/APP) - 巨人大哥 - 博客园 https://www.cnblogs.com/jurendage/p/13795640.html

https://mp.weixin.qq.com/s/ZLi1WlAa6yQUZzO_SV18sQ

生鲜电商中微服务体系的分层设计和领域划分

互联网后端架构 2020-12-13

 

5.Q&A

5.1 能不能在所有层使用数据持久层模型，简单快捷？

大家一定听说过不同层的数据模型的叫法不同的概念，比如数据持久层的模型对象叫DBO（database object）或者DPO（data persistence object),领域层的模型对象叫DMO（Domain Model Object）或者就叫Model，数据传输层的模型对象叫DTO（Data Transfer Object)。那为啥要这么多模型呢，直接使用Mybatis等ORM框架生成DBO，然后一路吐给前端不是更爽（还真有同事尝试立项写Mybatis插件来实现这种所谓的代码自动化）。我个人建议如果您真的是要搭建一个复杂的大系统，大平台，一定不要偷这种懒，最好的就是做到”一层一模型”（网关层使用应用层模型即可）。各层之间采用手动的数据赋值（getter，setter）来完成，或者使用一些转换框架来简化转换代码，个人在用getter/setter时感觉并不会耽误什么，在一个个set的时候，恰好可以对模型的字段细节进一步确认，并且拒绝使用BeanUtils.copyProperties()这种工具类，因为这样的工具类会让”一层一模型”形同虚设，开发会热衷于把DPO拷贝到领域中换个名字以保证可以用拷贝工具。下面我们来细谈下不能在每一层都是用数据持久层模型的具体原因：

• 应用层对接网关层，是向面向C端或者调用者的一个数据出口，但是调用者只需要这个出口输出用户感兴趣的数据，并且有些敏感数据不能吐出去。如果应用层（面向调用者）使用的仍然是数据库模型，而开发人员没有在应用层把无关值置空的话（相信我，需求一多，工作一忙，鬼才会在意这些细节），那么数据库里的整条记录就作为接口输出吐出去了。比如订单记录，用户订单列表可能只需要订单ID，商品名称，订单金额。而像商家结算价这种就不能吐出去，万一被有心人察觉到了，用户一定会投诉——你跟商家结算价200，卖给我400？
• 前端或者接口调用方会很痛苦，一个接口契约多一两个无关字段是没关系的，但是一个契约里给的30个字段，我只用到5个，前端会骂娘的，我亲眼见过这种事，设计原则里有个原则叫”迪米特法则”，也叫最小知识原则，接口设计也可以参考这个原则，尽量让你的调用方知道尽可能少的信息点就能完成相关的任务。
• “一层一模型”本质是解耦模型依赖。我在上家公司做架构师时为了兼顾开发的感受，决定让他们可以在领域层和基础设施层都是用数据持久层模型，而只需要在应用层做数据控制（解决第一个问题），然而我的妥协也慢慢露出弊端，开发有时候觉得某个数据库字段命名不合适修改之后，整个引用了该模型的微服务都需要修改，如果一层一模型的话，只需要关联数据库访问的服务修改下DPO和DM的映射就行了，其他上层微服务都是依赖DM的。虽然我们不鼓励随意改动数据库字段，但设计框架上最好能支持这种情况。

刚开始推广”一层一模型”的时候，会有耍小聪明的开发去把下一层的模型POJO直接拷贝过来改个名字，然后用BeanUtils.copyProperties()完成赋值，这样跟直接使用数据持久层模型就没有区别了，所以要杜绝这种情况的发生。

Java生鲜电商平台-SpringCloud微服务架构中核心要点和实现原理 - 巨人大哥 - 博客园 https://www.cnblogs.com/jurendage/p/11364846.html

应用层开发人员设计接口和契约

领域层开发人员划分领域、设计领域服务接口

应用层开发人员编写应用业务逻辑

领域层开发人员编写领域业务逻辑