一、领域驱动设计概述

概述

什么是领域驱动设计?

领域驱动设计（domain Drivern Design) ，针对业务模型的行为和数据

1. 通过将实现连接到持续进化的模型来满足复杂需求的软件开发方法
2. 领域模型是对业务模型的抽象

领域驱动适合的场景

DDD与微服务的区别

领域驱动设计是一种处理高度复杂域的设计思想，试图分离技术实现的
复杂性, 围绕业务概念构建领域模型来控制业务的复杂性，以解决软件难
以理解，难以演化等问题。
团队应用它可以成功地开发复杂业务软件系
统，使系统在增大时仍然保持[[敏捷]]。
领域驱动设计贯穿了整个软件开发的生命周期

• DDD的核心诉求是将业务架构映射到系统架构上，在响应业务变化调整业务架构时，也随之变化系统架构。
• 微服务追求业务层面的复用，设计出来的系统架构和业务一致；在技术架构上则系统模块之间充分解耦，可以自由地选择合适的技术架构，去中心化地治理技术和数据。

DDD的特点：

• 根据业务模型设计系统：根据业务语义抽象梳理设计成领域模型，而不是通过数据库等数据源驱动设计。
• 数据模型统一：通过真实业务背景，梳理出业务域模型自然会形成出参、入参、中间临时属性收口统一为域模型
• 业务模型与数据源无关：数据源更换，领域模型无感知，无须变更；一个域模型底层可能对应n个数据源；系统升级底层数据源结构改造时，变更对业务层是透明，域模型可无缝对接。
• 业务属性字段命名统一、引用唯一：MVC模式开发中，入参model/数据传输model/数据源model，同一个业务属性含义可能有多种不同的命名。
• 业务行为Action收口：原有开发模式下，一个Model类是一个POJO、DTO、DO，仅做数据传输，没有任何业务相关Action，属于典型的贫血模型。DDD中一个Model表述一个业务的域，有属性、业务行为Action，并且这个域的所有操作都在这个Model中，不仅有数据传输的作用也是一个具体的Service，是属于充血模型。这就可以做到业务操作高内聚、低耦合，系统更能直观体现业务逻辑。

DDD优缺点：

• 优点：系统演进更方便，分为业务复杂性变化的演进和业务数据量变化的演进；更方便测试
• 缺点：
  • 系统改造成DDD复杂，开发熟悉DDD思想困难。
  • 没有固定的协作方式，无法保障结果
  • 可视化程度有限，产出难以沉淀
  • 理论过于抽象，难以实例化，难以理解