【架构设计】领域驱动设计

领域驱动设计1. 为什么需要使用领域驱动设计1.1. 领域驱动设计的两个设计层面2. 战略设计落地3. 战术设计落地1. 为什么需要使用领域驱动设计业务与技术之前的关系比较混沌通常一个业务概念会揉合在多个不同的代码实体里面或者一个业务概念拥有多重身份导致在开发的时候一个类的体积臃肿类在使用的时候容易受不同的业务互相影响。1.1. 领域驱动设计的两个设计层面战略设计解决“系统应该划分为哪些边界、哪些模型、哪些团队负责”的问题。战术设计解决“在一个边界内如何用代码表达领域模型”的问题。先使用战略设计定义边界在使用战术设计定义实体、值对象、聚合根、领域服务、领域事件、仓储以及应用服务。战略设计优先于战术设计。没有清晰的边界直接使用实体、仓储、聚合模式容易变成“技术上的DDD”而不是真正的领域驱动。2. 战略设计落地明确领域和子域的划分。核心的业务是啥支撑核心业务的是啥哪些是通用的部分。例如订单域、库存域。明确通用语言。技术开发与领域专家达成名词上的统一。例如消费者使用当前系统进行下单的用户。梳理并划分限界上下文。同一个实体在不同的上下文中可能含义不一样区分实体的不同场景就是上下文。例如订单上下文优惠券上下文。定义上下文之间的映射。上下文与上下文之间的关系实际上就是场景与场景之间的关联比如A场景产生的数据往往是B场景的启动条件。例如客户-供应商库存是客户订单是供应商订单发生变化会影响系统中的库存。3. 战术设计落地选定一个子域进行设计。例如订单域。思考这个上下文中最重要的实体是那个找出实体进行定义。例如订单。找出实体中的值对象不是单纯的一个变量是充血模型带有自身一些校验规则。例如订单中商品价格。抽象出这个子域中需要实现的事件这些事件的集合就是聚合根聚合根中的每一个聚合实际上就是事件。例如校验商品价格校验优惠券规则。把多个聚合中公共的行为抽象为领域服务这个是这个子域中可以提供的公共服务。例如商品库存扣减。将这个领域中可以实现的操作定义对应的领域事件领域事件用于给其他的消费者进行通知。例如下单成功事件下单失败事件。定义仓储仓储就是实现数据持久所需要做的实现后续可以通过Mybatis或者其他自动半自动的框架实现数据的消费。例如Order Repository。