从MVC 到DDD 架构

一、前言

二、MVC架构

三、DDD架构

四、我为什么会使用DDD？

五、DDD架构分层

一、前言

最近在做一个项目，使用的是DDD架构思，觉得很不错，在此记录下。

二、MVC架构

MVC是一种经典的软件架构模式，主要用于构建用户界面和应用程序逻辑的分离。以下是MVC架构的主要组成部分：

模型（Model）：模型表示应用程序的数据和业务逻辑。它负责处理数据的读取、存储、验证和更新，以及定义业务规则和逻辑。
视图（View）：视图是用户界面的可视化呈现，负责向用户展示数据和接收用户的输入。它通常根据模型的状态来更新自己，并将用户的操作反馈给控制器。
控制器（Controller）：控制器接收来自用户界面的输入，并根据输入调用适当的模型和视图进行处理。它负责协调模型和视图之间的交互，并处理应用程序的逻辑和流程控制。
MVC架构的主要目标是实现关注点分离，将应用程序的数据、逻辑和呈现分离开来，以便更好地管理和维护代码。它提供了一种结构化的方法，使开发人员能够更好地组织代码，并实现可复用、可扩展和可测试的应用程序。

在这篇有具体讲解，MVC 架构思路

三、DDD架构

DDD是一种软件开发方法论，它强调通过对业务领域的深入理解和建模来指导软件设计和开发。DDD的核心是将业务领域的知识和概念融入软件设计中。以下是DDD架构的主要特点：

领域模型（Domain Model）：领域模型是对业务领域的概念和规则的抽象建模。它将业务规则和逻辑直接编码到软件中，以便更好地反映实际业务需求。
领域驱动设计（Domain-Driven Design）：DDD强调通过与领域专家密切合作，深入理解业务需求，并将这些需求转化为软件设计的核心。它鼓励使用领域语言和概念来进行沟通和设计，以确保软件与业务紧密关联。
聚合根（Aggregate Roots）：聚合根是DDD中的重要概念，它是一组相关对象的根，具有事务边界和一致性边界。聚合根通过封装和管理内部对象来维护业务规则和完整性。
领域服务（Domain Services）：领域服务是一些无状态的操作，用于执行与业务关联的操作。它们通常在领域模型之外，提供一些跨领域对象的操作和协调。
DDD的主要目标是通过深入理解业务领域和建立有效的领域模型，来解决复杂业务问题。它强调将业务逻辑和行为嵌入到软件设计中，以实现更好的可维护性、可扩展性和可测试性。

四、我为什么会使用DDD？

首先我们先明白MVC的特点——简单、容易、好理解；但也正因为简单的分层逻辑，在适配较复杂的场景并且需要长周期的维护时，代码的迭代成本就会越来越高。

当接触过较大型且已经长期维护项目的 MVC 架构，会发现这里的 DAO、PO、VO 对象，在 Service 层相互调用。那么长期开发后，就导致了各个 PO 里的属性字段数量都被撑的特别大。就像一种“裤子乱穿”的现象，第一个人看到该类时，发现这个刚好是我自己想用的，直接拿走使用，调方法；第二个人看到了，发现也是我需要的，但缺少了某些功能或某些字段，就自己加上，然后调方法使用，第三个人……等等，这个方法就像“公共裤子一样，被许多人使用，并且裤子越来越大，越来越臃肿，产生的调用也紊乱，如下图所示。

而 DDD 架构首先以解决此类问题为主，DDD 架构的模型分层，则是以人为视角，一个人就是一个领域，一个领域内包括他所需的衣服、裤子、袜子、鞋子。虽然刚开始有点浪费空间，但随着软件的长周期发展，后续的维护成本就会降低；将各个属于自己领域范围内的行为和逻辑封装到自己的领域包下处理。这也是 DDD 架构设计的精髓之一。它希望在分治层面合理切割问题空间为更小规模的若干子问题，而问题越小就容易被理解和处理，做到高内聚低耦合。这也是康威定律所提到的，解决复杂场景的设计主要分为：分治、抽象和知识。

五、DDD架构分层

如下是 DDD 架构的一种分层结构，也可以有其他种方式。

接口定义 api：因为微服务中引用的 RPC 需要对外提供接口的描述信息，也就是调用方在使用的时候，需要引入 Jar 包，让调用方好能依赖接口的定义做代理。

应用封装 app：这是应用启动和配置的一层，如一些 aop 切面或者 config 配置，或者将 mapper 等.xml 文件，以及打包镜像（yml、yaml）都是在这一层处理。你可以把它理解为专门为了启动服务而存在的。

领域封装 domain：领域模型服务，是一个非常重要的模块。无论怎么做DDD的分层架构，domain 都是肯定存在的。在一层中会有一个个细分的领域服务，在每个服务包中会有【模型、仓库、服务】这样3部分，例如权限领域服务、业务领域服务、支付领域服务等（里面包括model、repository、service等）。