领域驱动设计 (DDD): 三层架构到 DDD 架构演化
三层架构的问题
在前文中,我从基础代码的角度探讨了如何运用领域驱动设计(DDD)来实现高内聚低耦合的代码。本篇文章将从项目架构的角度,继续探讨三层架构与 DDD 之间的演化过程,以及 DDD 如何优化架构的问题。
三层架构作为一种常见的软件架构模式,将应用程序分为展示层、业务逻辑层和数据访问层,具有以下优点:
分离关注点: 三层架构将不同功能模块分隔开,使每个模块专注于特定任务,降低了代码复杂性。
可维护性和可扩展性: 不同层之间的松耦合使得对某一层的修改不会影响其他层,有助于系统的维护和扩展。
可测试性: 不同层的独立性使得单元测试和集成测试更容易实现,有助于确保代码质量。
然而,尽管三层架构有其优点,在处理复杂业务时,三层架构也可能面临一些问题。具体有:
业务逻辑分散: 在三层架构中,业务逻辑往往分散在不同的层中,导致业务流程难以理清,影响了代码的可读性和可维护性。
领域模型贫血: 三层架构中,领域逻辑和数据存储混合在一起,导致领域模型的业务方法受限,难以表达复杂的业务规则。
过度依赖数据存储: 不同层之间对数据存储的依赖紧密,当切换数据存储介质时,需要大量修改代码。
具体具体示意如下图:
![](https://static001.geekbang.org/infoq/0f/0f696ccfa1a1bfef141a9021af5e0830.png)
随着业务的不断复杂化,service 层变得越来越庞大,服务之间的引用也变得越来越混乱,这为项目带来了风险和不确定性。
三层架构演化到 DDD
在三层架构的演化过程中,有时会尝试引入额外的"Manager"层来管理服务层的功能,但这并不是 DDD 所倡导的概念。在 DDD 中,更加关注领域的划分和内聚,以及如何将领域模型与业务需求对应起来。
一般情况下,三层架构的问题可以通过引入领域驱动设计来解决。在以下内容中,我们将重点放在如何将 DDD 思想融入现有的三层架构中,以实现更高内聚、更低耦合的代码架构。
领域的划分: DDD 将 service 层按业务场景划分成不同的领域,每个领域内包含实体、值对象、聚合根等元素。
内聚的领域: 在领域内,业务尽量内聚,避免领域之间的耦合。每个领域内部可以根据需要建立更细粒度的子域,进一步提高内聚性。
应用层的组合: 引入一个 Application 层,将领域内的 service 组合调用,形成业务服务,避免服务之间直接引用,降低耦合度。
经过我们的修改,三层架构可以(组合和聚合)演进到右侧架构模式,通过这种方式,我们能够更好地组织和管理代码,实现领域内高内聚低耦合的目标。
![](https://static001.geekbang.org/infoq/0a/0a0c71f84e5fa410dbab18b816ad94fd.png)
代码组织
在进行了基础代码的优化后,接下来我们将探讨如何根据领域驱动设计(DDD)思想来优化整体代码架构。经过前面的分析,我们大致了解了 DDD 的项目结构,并且明确了每个层次的职责。现在,让我们更详细地探讨每个层次的代码组织。
Domain 层: 该层是 DDD 的核心,包含了领域对象、值对象、聚合根等,以及领域内的业务逻辑和规则。在领域内,业务逻辑应该尽量内聚,领域间应该尽量松耦合。
基础架构层: 包括仓储实现,缓存实现,队列实现等等系列系统需要的基础能力,这一层的目的是为整个项目提供基础支持。
Application 层: 这一层用于组合领域内的服务,形成具体的应用用例。它不包含具体的业务逻辑,只是通过调用领域内的服务来实现具体的功能。
UI 层: UI 层负责展示数据和接收用户输入,它不包含业务逻辑,只是通过调用 Application 层来触发业务流程。
具体架构类似如下图:
![](https://static001.geekbang.org/infoq/ee/eee32f8795d5a506e3c74c9f3921b9b3.png)
当将领域驱动设计(DDD)引入到项目架构中,代码的组织方式会有所不同,以更好地体现领域的业务逻辑和关系。让我们详细解释每个层次的代码组织,为了保证阅读的连贯性,我们从引用的最低层(domain 层)开始说起
Domain 层:
Domain 层是 DDD 的核心,它包含了领域对象、值对象、聚合根等,以及领域内的业务逻辑和规则。在这一层,你应该更关注领域的核心业务,让代码更贴近业务现实。以下是一些代码组织的思路:
实体和值对象: 领域对象可以分为实体和值对象。实体是有唯一标识的对象,通常代表业务概念;值对象是没有唯一标识的对象,它们通常用来描述实体的属性。在这一层,你应该为每个实体和值对象定义其属性和行为。
聚合和聚合根: 将相关联的实体和值对象组合成聚合,聚合根是聚合的入口。聚合根负责保持聚合内的一致性,它是领域模型的核心部分。
领域服务: 领域服务用于处理一些领域范围内的业务逻辑,它们不属于任何具体的实体或值对象。将这些逻辑封装在领域服务中可以使领域模型更加清晰。
通用工具类: 通用工具类是一些与领域相关的辅助方法,可以被领域内的多个实体或值对象使用。将通用工具类放在领域层可以更方便地供领域内的实体使用,避免在其他层重复实现。
![](https://static001.geekbang.org/infoq/9a/9a2c42bf750c7e31ec8ed1b8152a69dc.png)
在 domain 域内提供,entity(实体),valueobj(值对象),AggregateRoot(聚合根),仓储接口(IRepository),事件驱动相关(event)
基础架构层:
在基础架构层,我们主要关注与系统的基础设施和通用功能。这一层包含仓储模式和接口适配器,用于封装数据存储操作并为领域层提供统一的数据访问接口。通用工具类也可以在这里定义和实现,为领域层和应用层提供通用的辅助功能。基础架构层的代码组织通常如下:
第三方库封装: 如果项目使用了第三方库或框架,你可以在基础架构层进行封装,以便在其他层中更方便地使用。封装可以包括对第三方库的初始化、配置以及封装特定的操作接口。
仓储接口和适配器: 在基础架构层中定义仓储接口,以及不同数据存储介质的适配器实现。这样可以将数据访问操作与领域层解耦,同时实现数据存储的切换。
中间件实现: 如果系统使用了中间件,如缓存、消息队列等,你可以在基础架构层实现中间件的具体操作。这有助于将与中间件相关的逻辑隔离在基础架构层中。
事件驱动实现: 如果系统采用了事件驱动的架构,你可以在基础架构层实现事件的发布与订阅机制,以及事件的处理逻辑。
![](https://static001.geekbang.org/infoq/ad/adc39162842291b63d76f66672ca1855.png)
如上图,使用 redis 提供缓存,使用 kafka 提供消息队列,使用 guava 提供事件驱动,仓储层负责实现仓储功能
Application 层:
Application 层用于组合领域内的服务,形成具体的应用用例。它不包含具体的业务逻辑,而是通过调用领域内的服务来实现功能。在这一层,你可以有以下的组织方式:
应用服务: 应用服务负责处理用户请求,协调领域内的服务,形成具体的用例。每个应用服务通常对应一个用户操作,它们应该是轻量级的,不涉及具体的业务逻辑。
DTO(数据传输对象): DTO 负责承接前端传入的数据,为领域层转换为对应的业务参数。它们将用户输入的数据进行封装,以便传递给领域层进行处理。
数据转换: 在应用层,你可能需要将领域对象转换为 DTO,用于与 UI 层进行数据交互。数据转换负责将领域对象的数据映射到 DTO 中,只暴露需要的数据字段。
UI 层:
UI 层负责展示数据和接收用户输入,它不包含业务逻辑,只是通过调用 Application 层来触发业务流程。在这一层,主要形式有 api,job 和视图页面等等
总结
当我们将三层架构向 DDD 演进时,我们逐步重塑我们的代码组织,让领域层成为核心,包含实体、值对象、聚合根和领域服务,以最佳方式捕捉业务逻辑和规则。基础架构层负责提供通用能力,如仓储实现、中间件封装等,为领域层提供支持。应用层负责将领域内的服务组合成具体的应用用例,通过调用领域服务实现功能。最后,UI 层负责与用户交互,通过调用应用层触发业务流程。这种结构使得不同层次之间的耦合度降低,代码变得更清晰、可维护和可扩展。
在我们演进的过程中,重要的是不仅仅是技术层面的变化,更是对于业务的深入理解和把握。DDD 不仅仅是一种架构模式,更是一种用于探索和应对复杂业务的方法论。通过将 DDD 思想融入我们的架构设计中,我们能够更好地应对日益复杂的业务需求,使得我们的系统更具弹性和适应性,从而为日后面临复杂的业务奠定基础。
版权声明: 本文为 InfoQ 作者【付威】的原创文章。
原文链接:【http://xie.infoq.cn/article/002cd4a6de15864e91e18c93d】。文章转载请联系作者。
评论