什么是DDD领域驱动模型?

2023年3月29日

讲领域驱动模型之前,先谈谈目前较为流行的数据驱动模型,传统的数据驱动一般为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

服务器托管,北京服务器托管,服务器租用 http://www.hhisp.net

hackdl

咨询热线/微信 13051898268