讲领域驱动模型之前,先谈谈目前较为流行的数据驱动模型,传统的数据驱动一般为MVC架构,也就是经典的三层架构,业务集中在service层,在业务需求不断的迭代时,代码也会随着业务越来越复杂而变得越来越臃肿,而领域驱动模型是通过对边界的划分将复杂业务领域化,利于维护,易于扩展。
贫血模型和充血模型是什么?
贫血模型:对象里只有get和set方法,所有的业务逻辑都在业务逻辑层
优点是系统的层次结构清楚,各层之间单向依赖
缺点是对象只作传输介质,只有数据没有行为
充血模型:领域对象里封装了数据和行为
什么是DDD领域模型?
DDD领域模型是面向对象设计的,基于充血模型,解耦业务系统,划分业务模块,以业务为主导,自顶向下的进行业务领域划分,将大的业务需求进行拆分。
举个例子:
以电商订单场景为例,假如我们现在要做一个电商订单下单的需求。涉及到用户选定商品，下订单，支付订单，对用户下单时的订单发货。
MVC架构里面，我们常见的做法是在分析好业务需求之后，就开始设计表结构了，订单表，支付表，商品表等等。然后编写业务逻辑。这是第一个版本的需求，功能迭代饿了，订单支付后我可以取消，下单的商品我们退换货，是不是又需要进行加表，紧跟着对于的实现逻辑也进行修改。功能不断迭代，代码就不断的层层往上叠。
DDD架构里面，我们先进行划分业务边界。这里面核心是订单。那么订单就是这个业务领域里面的聚合逻辑体现。支付，商品信息，地址等等都是围绕着订单实体。订单本身的属性决定之后，类似于地址只是一个属性的体现。当你将订单的领域模型构建好之后，后续的逻辑边界与仓储设计也就随之而来了。
MVC和DDD的区别?
MVC三层架构,SQL都是针对于特定的业务进行编写,复用性差,如果有新的业务需求,那么只能另写满足新业务需求的SQL,对于简单的系统,这么做的好处就是版本迭代快,但是对于复杂的系统来说,代码会逐渐混乱,最终导致无法正常维护。
而对于DDD领域驱动,我们需要提前理清所有的业务,定义领域模型的属性和方法,新功能需求的开发,都是基于之前定义好的领域模型来完成。
四层架构
用户交互层：web请求，rpc请求，mq消息等外部输入均被视为外部输入的请求，可能修改到内部的业务数据。
业务应用层：与MVC中的service不同的不是，service中存储着大量业务逻辑。但在应用服务的实现中（以功能点为维度），它负责编排、转发、校验等。（在设计和开发时，不要将本该放在领域层的业务逻辑放到应用层中实现。因为庞大的应用层会使领域模型失焦，时间一长你的服务就会演化为传统的三层架构，业务逻辑会变得混乱。）
领域层：或称为模型层，系统的核心，负责表达业务概念，业务状态信息以及业务规则。即包含了该领域（问题域）所有复杂的业务知识抽象和规则定义。该层主要精力要放在领域对象分析上，可以从实体，值对象，聚合（聚合根），领域服务，领域事件，仓储，工厂等方面入手。
基础设施层：主要有2方面内容，一是为领域模型提供持久化机制，当软件需要持久化能力时候才需要进行规划；一是对其他层提供通用的技术支持能力，如消息通信，通用工具，配置等的实现。
如有不对的地方,欢迎大家指正。
参考文献
https://blog.csdn.net/franktyf/article/details/112156170
https://mp.weixin.qq.com/s/x4HjK8t6mPAg1vQWa3PrSg