关于DDD设计模式的各种疑问：什么是DDD架构？

原创

已于 2024-04-17 21:31:41 修改 · 6.9k 阅读

标签

#设计模式 #架构

于 2024-04-17 21:17:56 首次发布

本文详细介绍了领域驱动设计（DDD）架构，对比了DDD与DCI、CQRS、MVC、微服务架构及BDD的区别，阐述了DDD中聚合、仓储、工作单元等概念。还给出货物运输和秒杀系统两个案例，最后分析了DDD的优缺点及实现难题。

关于DDD架构中的各种概念，请先参考一篇文章：什么是DDD（领域驱动设计）？这是我见过最容易理解的一篇关于DDD 的文章了

下面是关于这个架构的各种说明。

1 DDD和其他架构模式的区别（建议看完文章再看此问题）

1.1 DDD、DCI和CQRS架构的区别

1.1.1 区别

领域驱动设计（DDD）、**数据-上下文-交互模型（DCI）和命令查询责任分离（CQRS）**是三种不同的软件架构理论和模式，各自针对特定的设计挑战提供解决方案。虽然它们可以相互补充，但它们在设计软件系统时的侧重点和方法各不相同。

领域驱动设计（DDD）

核心概念：DDD是一种复杂软件设计的方法论，强调以业务领域为中心的软件开发。它鼓励开发人员和领域专家（如业务分析师）紧密合作，以确保软件模型精确地反映业务领域的复杂性。
目的：通过创建一个丰富的领域模型来管理复杂性，该模型涵盖了业务的状态和行为。
实施：包括实体、值对象、聚合、领域事件、服务和领域仓储等概念，以确保模型的完整性和业务规则的实施。

数据-上下文-交互模型（DCI）

核心概念：DCI是一种编程范式，旨在提高软件的可理解性，并更好地将用户的心智模型映射到代码中。它通过将系统的行为分配到可单独理解的上下文中来实现这一点。
目的：使软件的行为和用户的交互更直观，通过上下文和角色的概念，将数据对象在特定场景下的行为进行组织。
实施：通常涉及将对象的行为（方法）分配给特定的运行时角色，这些角色定义在交互的上下文中，以表达特定的场景或用例。

命令查询责任分离（CQRS）

核心概念：CQRS是一种通过将应用程序的读操作（查询）和写操作（命令）分离开来来提高效率、可扩展性和维护性的模式。
目的：优化读和写操作的处理，允许它们分别进行优化和扩展。这种分离可以提高性能和可伸缩性，特别是在大规模和高并发的应用场景中。
实施：在CQRS中，命令操作负责更改数据的状态，而查询操作则专注于数据的展示。这通常意味着使用不同的模型来处理读和写操作，甚至可能在物理上分离数据存储。

总结

DDD 关注于创建一个反映领域复杂性的丰富模型，主要应对业务逻辑的复杂性。
DCI 侧重于提高代码的可读性和对用户行为的模拟，关注点在于行为的组织和表达。
CQRS 关注于提升数据操作的效率，通过物理和逻辑上的分离来优化读写操作的性能。

这三者可以相互补充，在同一个项目中根据不同的需求采用不同的模式来达到最优的设计和实现。例如，在一个采用DDD的系统中，可以实现CQRS来优化数据处理，并通过DCI来改进某些特定用例的代码表达和行为模拟。

1.1.2 三种软件架构理论和模式针对的设计挑战

领域驱动设计（DDD） 针对的挑战是如何处理业务逻辑的复杂性。它提供了一种方法，通过与领域专家紧密合作和细致的模型设计，确保软件能够准确反映复杂业务领域的需求和规则。
数据-上下文-交互模型（DCI） 针对的挑战是如何提高软件的可理解性和保持代码与用户的心智模型一致。DCI通过上下文和角色来组织代码，帮助开发者和用户更直观地理解软件的行为。
命令查询责任分离（CQRS） 针对的挑战是如何在大数据量和高并发的情况下提高软件系统的性能和可扩展性。CQRS通过将读操作和写操作分离，允许独立优化和扩展各自的处理流程和数据模型。

1.2 DDD和MVC

1.2.1 DDD和MVC的区别

领域驱动设计（DDD）和模型-视图-控制器（MVC）是两种不同层次上的软件设计方法，它们在设计目的和实现策略上具有明显的差异和一些共通之处。以下是DDD和MVC设计模式的主要异同点：

相同点

模型的概念：在DDD和MVC中都有“模型”这一概念。在MVC中，模型代表数据和业务逻辑，是应用程序的核心；在DDD中，模型（尤其是领域模型）是理解和实现业务领域复杂性的关键，包括实体、值对象、聚合等。
分层：两者都鼓励在设计中进行分层，虽然具体的层次结构和职责可能不同。MVC通过将应用分为模型、视图和控制器三部分来组织代码，而DDD通常会有更复杂的分层，如领域层、应用层、基础设施层等。

不同点

设计焦点：

MVC：MVC主要关注的是用户界面（UI）的设计，以及用户界面与应用程序后端逻辑的分离。它的核心目的是使得用户界面（视图）、数据（模型）和输入控制（控制器）相互独立，简化Web或桌面应用程序的开发和维护。
DDD：DDD关注于创建一个反映业务领域的丰富和精确的领域模型。它致力于解决复杂业务逻辑的问题，通过领域模型来促进大型软件项目的开发，特别是在业务规则频繁变更或极其复杂的情况下。

使用场景：

MVC：更适用于需要清晰分离用户界面和业务逻辑的应用，如Web应用和桌面应用。MVC模式帮助开发者组织代码，使得应用的用户界面易于修改而不影响数据处理逻辑。
DDD：适用于业务规则复杂且需要深入理解业务以支持软件实现的场景，特别是在企业级应用中。DDD通过强调与领域专家的合作和持续的模型精化，助力开发团队更好地管理复杂性和变化。

实现复杂度：

MVC：通常实现起来相对简单，因为它主要处理的是如何从UI接收用户操作、如何回应这些操作以及如何展示数据。
DDD：实现复杂度较高，因为它涉及深入的领域建模，需要领域专家的密切合作，并且可能涉及复杂的模式和架构策略，如聚合、领域事件、仓储等。

总结来说，MVC和DDD在软件设计中服务于不同的目的和层面。MVC是一种UI设计模式，帮助开发者组织和分离UI代码，而DDD是一种更全面的架构方法，专注于解决业务复杂性问题，并通过建立一个反映真实业务的模型来增强软件的可维护性和可扩展性。在实际应用中，两者可以互相补充：DDD的领域模型可以成为MVC中M（模型）的实现方式，
而MVC可以管理DDD中定义的模型的展示和用户交互。

1.2.2 MVC中的controller类的方法可以理解为ddd的应用层吗，其中使用mybatis构建的数据访问层可以理解为ddd的仓储吗？构建的model包中的多个类或者复合类可以理解为领域对象和聚合吗？service层实现的具体业务逻辑可以理解为领域服务吗？

您提出的问题非常好，通过比较MVC模式中的各个组成部分与领域驱动设计（DDD）的概念，可以更好地理解这两种设计方法的异同以及如何在实际项目中应用它们。下面是根据您的问题的具体解释：

1. MVC中的Controller与DDD的应用层

在MVC模式中，Controller 负责接收用户的输入并调用相应的模型和视图去执行用户的请求。在DDD中，应用层则负责协调领域层和基础设施层来执行特定的用户用例或应用逻辑。

相似性：MVC的Controller和DDD的应用层都充当了输入处理和应用逻辑的协调者，负责从UI层获取请求，执行业务逻辑，并最终返回响应。
区别：Controller通常直接管理用户输入和输出，而应用层则更专注于执行特定的应用逻辑，且通常不处理直接的用户输入输出（这部分由接口层如REST API处理）。应用层更多地与领域服务、仓储等交互，而不仅仅是数据和视图。