前言：

在传统的 MVC 架构下开发时，通常采用的是 “数据驱动设计”（自底向上设计开发）：根据需求先建立数据库表，将数据库表映射为持久化对象（PO），然后在服务层通过 CRUD 操作进行 过程式编程，这导致模型（贫血模型）无法直观地反映业务实际情况。在多个场景下出现了功能相似但又有所不同的需求时，经常导致重复编写相似的代码。同时，由于缺乏对业务领域的深入理解和沉淀，服务间的调用往往缺乏清晰的结构，导致逻辑交织在一起，这不仅降低了系统的可读性，也给系统的可维护性带来了挑战。最终造成了 逻辑上的分散，系统整体的内聚性不足。但是这种架构设计的优点是：非常简单，能在小规模团队下完成快速迭代和交付。

一 什么是"DDD领域驱动设计"

2004 年埃里克·埃文斯（Eric Evans）发表了《领域驱动设计》（Domain-Driven Design

–Tackling Complexity in the Heart of Software）这本书，从此领域驱动设计（Domain Driven Design，简称 DDD）诞生。DDD 核心思想是通过领域驱动设计方法定义领域模型，从而确定业务和应用边界，保证业务模型与代码模型的一致性。

DDD是一种设计思想（方法论），通过事件风暴使用通用语言对业务进行领域建模，通过限界上下文进行合理的领域拆分，可以使得领域模型转向微服务的设计和落地，从而解决复杂软件难以理解，难以演进，也可以解决微服务业务界限难以界定的问题。

DDD告诉我们：开发过程不再以数据模型为起点，而是以领域模型为出发点，领域模型对应业务实体。程序中主要表现为类、聚合根和值对象，更加关注业务语义的显性化表达，而不是数据的存储和数据之间的关系。

领域驱动的研发过程为：需求分析 ----> 领域分析 ----> 领域建模 ----> 核心业务逻辑 ----> 技术细节（DB、Cache、Message.....）

数据驱动的研发过程为：需求分析 ----> 数据建模（ER图） ----> 建库建表，写DAO层 ----> 编写业务逻辑

二 为什么要用"DDD领域驱动设计"？

优点

DDD最大的好处是：接触到需求第一步就是考虑领域模型，而不是将其切割成数据和行为，然后数据用数据库实现，行为使用服务实现，最后造成需求的首肢分离。DDD让你首先考虑的是业务语言，而不是数据。DDD强调业务抽象和面向对象编程，而不是过程式业务逻辑实现。重点不同导致编程世界观不同。

• 面向对象设计，数据行为绑定，告别贫血模型；
• 降低复杂业务的复杂度，分而治之；
• 优先考虑领域模型，而不是切割数据和行为；
• 业务语义显性化，准确传达业务规则，业务优先；
• 代码即设计，通过领域设计即可很清晰的实现代码；
• 它通过边界划分将复杂业务领域简单化，帮我们设计出清晰的领域和应用边界，可以很容易地实现业务和技术统一的架构演进；
• 领域知识共享，提升协助效率；
• 增加可维护性和可读性，延长软件生命周期；
• 中台化的基石。

缺点

• 需要开发人员完全理解业务，包括宏观到微观，设计到落地实现，提升了认知难度
• 与经典的过程式设计：Transaction Script不符，不太符合很多初级程序员先入为主的直觉
• 将数据不⼀致的影响⾯进⼀步放⼤，由微服务级别放⼤到微服务内的聚合级别。
• 新项目初始开发阶段投入资源大

我们看上面这张图：横坐标代表业务复杂度，纵坐标代表需要付出的努力（增加的工作量）；

我们可以看到：

• 传统的过程式设计（Transaction Script）开发模型中，随着业务复杂度提升，增加的工作量呈指数级上升
• 领域模型（Domain Model）中，虽然一开始的工作量很高，但是一旦成型，随着业务复杂度的提高，代码开发的复杂度，业务工作量仅仅是线性提升；
• 表模型（Table Module）由于不属于面向对象的设计，在java开发中用的很少，这里不做讨论。

虽然DDD的设计能降低未来开发的工作量与复杂度；但是并不是万能的，不要盲目选择DDD

抛开业务谈设计就是耍流氓，只有很复杂的系统可能用到DDD；简单的业务软件设计，还是选择经典的Transaction Script过程式设计更高效与经济

三 领域驱动设计过程

四 MVC（Model-View-Controller）与DDD架构的区别

1. 关注点不同：

   • MVC架构关注于将应用程序的不同部分分为模型（Model/Dao）、视图（View）和控制器（Controller），以实现分层和关注点分离。它主要解决的问题是用户界面与应用逻辑之间的分离，以及实现交互和数据展示。
   • DDD架构关注于对领域知识的建模和实现，将领域层（Domain Layer）作为核心，并通过领域模型来表达业务领域的概念和规则。它主要解决的问题是在复杂的业务领域中，如何设计和组织代码以实现业务需求。

2. 层次结构不同：

   • MVC架构分为三个主要层次：模型（Model）、视图（View）和控制器（Controller）。模型层负责处理数据和业务逻辑，视图层负责展示数据给用户，控制器层负责处理用户的输入和操作。
   • DDD架构也分为不同的层次，包括领域层（Domain Layer）、应用层（Application Layer）、基础设施层（Infrastructure Layer）等。领域层是核心，负责定义和实现领域模型和业务逻辑，应用层负责协调和组织领域层的操作，基础设施层负责与外部资源的交互。DDD分层依靠事件驱动，通过事件建立模型，合理划分边界，建立领域对象，定义符合DDD分层架构思想的代码模型，以此保证业务模型与代码模型的一致性。

3. 设计思想不同：

   • MVC架构的设计思想是通过分离用户界面、应用逻辑和数据操作，实现可维护、可扩展的应用程序。它强调关注点分离和模块化设计。
   • DDD架构的设计思想是通过领域模型来表达业务领域的概念和规则，强调将业务逻辑放在核心领域层中，以实现高内聚、松耦合的设计。

更详细的名词解释，代码演示，请看后续