领域驱动设计(DDD):三层架构到DDD架构演化

三层架构的问题 在前文中,我从基础代码的角度探讨了如何运用领域驱动设计(DDD)来实现高内聚低耦合的代码。本篇文章将从项目架构的角度,继续探讨三层架构与DDD

三层架构的问题

在前文中,我从基础代码的角度探讨了如何运用领域驱动设计(DDD)来实现高内聚低耦合的代码。本篇文章将从项目架构的角度,继续探讨三层架构与DDD之间的演化过程,以及DDD如何优化架构的问题。

三层架构作为一种常见的软件架构模式,将应用程序分为展示层、业务逻辑层和数据访问层,具有以下优点:

  1. 分离关注点: 三层架构将不同功能模块分隔开,使每个模块专注于特定任务,降低了代码复杂性。
  2. 可维护性和可扩展性: 不同层之间的松耦合使得对某一层的修改不会影响其他层,有助于系统的维护和扩展。
  3. 可测试性: 不同层的独立性使得单元测试和集成测试更容易实现,有助于确保代码质量。

然而,尽管三层架构有其优点,在处理复杂业务时,三层架构也可能面临一些问题。具体有:

  1. 业务逻辑分散: 在三层架构中,业务逻辑往往分散在不同的层中,导致业务流程难以理清,影响了代码的可读性和可维护性。
  2. 领域模型贫血: 三层架构中,领域逻辑和数据存储混合在一起,导致领域模型的业务方法受限,难以表达复杂的业务规则。
  3. 过度依赖数据存储: 不同层之间对数据存储的依赖紧密,当切换数据存储介质时,需要大量修改代码。

具体具体示意如下图:

随着业务的不断复杂化,service层变得越来越庞大,服务之间的引用也变得越来越混乱,这为项目带来了风险和不确定性。

三层架构演化到DDD

在三层架构的演化过程中,有时会尝试引入额外的"Manager"层来管理服务层的功能,但这并不是DDD所倡导的概念。在DDD中,更加关注领域的划分和内聚,以及如何将领域模型与业务需求对应起来。

一般情况下,三层架构的问题可以通过引入领域驱动设计来解决。在以下内容中,我们将重点放在如何将DDD思想融入现有的三层架构中,以实现更高内聚、更低耦合的代码架构。

  1. 领域的划分: DDD将service层按业务场景划分成不同的领域,每个领域内包含实体、值对象、聚合根等元素。
  2. 内聚的领域: 在领域内,业务尽量内聚,避免领域之间的耦合。每个领域内部可以根据需要建立更细粒度的子域,进一步提高内聚性。
  3. 应用层的组合: 引入一个Application层,将领域内的service组合调用,形成业务服务,避免服务之间直接引用,降低耦合度。

经过我们的修改,三层架构可以(组合和聚合)演进到右侧架构模式,通过这种方式,我们能够更好地组织和管理代码,实现领域内高内聚低耦合的目标。

代码组织

在进行了基础代码的优化后,接下来我们将探讨如何根据领域驱动设计(DDD)思想来优化整体代码架构。经过前面的分析,我们大致了解了DDD的项目结构,并且明确了每个层次的职责。现在,让我们更详细地探讨每个层次的代码组织。

  1. Domain层: 该层是DDD的核心,包含了领域对象、值对象、聚合根等,以及领域内的业务逻辑和规则。在领域内,业务逻辑应该尽量内聚,领域间应该尽量松耦合。
  2. 基础架构层: 包括仓储实现,缓存实现,队列实现等等系列系统需要的基础能力,这一层的目的是为整个项目提供基础支持。
  3. Application层: 这一层用于组合领域内的服务,形成具体的应用用例。它不包含具体的业务逻辑,只是通过调用领域内的服务来实现具体的功能。
  4. UI层: UI层负责展示数据和接收用户输入,它不包含业务逻辑,只是通过调用Application层来触发业务流程。

具体架构类似如下图:

当将领域驱动设计(DDD)引入到项目架构中,代码的组织方式会有所不同,以更好地体现领域的业务逻辑和关系。让我们详细解释每个层次的代码组织,为了保证阅读的连贯性,我们从引用的最低层(domain层)开始说起

Domain层:

Domain层是DDD的核心,它包含了领域对象、值对象、聚合根等,以及领域内的业务逻辑和规则。在这一层,你应该更关注领域的核心业务,让代码更贴近业务现实。以下是一些代码组织的思路:

  • 实体和值对象: 领域对象可以分为实体和值对象。实体是有唯一标识的对象,通常代表业务概念;值对象是没有唯一标识的对象,它们通常用来描述实体的属性。在这一层,你应该为每个实体和值对象定义其属性和行为。

  • 聚合和聚合根: 将相关联的实体和值对象组合成聚合,聚合根是聚合的入口。聚合根负责保持聚合内的一致性,它是领域模型的核心部分。

  • 领域服务: 领域服务用于处理一些领域范围内的业务逻辑,它们不属于任何具体的实体或值对象。将这些逻辑封装在领域服务中可以使领域模型更加清晰。

  • 通用工具类: 通用工具类是一些与领域相关的辅助方法,可以被领域内的多个实体或值对象使用。将通用工具类放在领域层可以更方便地供领域内的实体使用,避免在其他层重复实现。

在domain域内提供,entity(实体),valueobj(值对象),AggregateRoot(聚合根),仓储接口(IRepository),事件驱动相关(event)

基础架构层:

在基础架构层,我们主要关注与系统的基础设施和通用功能。这一层包含仓储模式和接口适配器,用于封装数据存储操作并为领域层提供统一的数据访问接口。通用工具类也可以在这里定义和实现,为领域层和应用层提供通用的辅助功能。基础架构层的代码组织通常如下:

  • 第三方库封装: 如果项目使用了第三方库或框架,你可以在基础架构层进行封装,以便在其他层中更方便地使用。封装可以包括对第三方库的初始化、配置以及封装特定的操作接口。

  • 仓储接口和适配器: 在基础架构层中定义仓储接口,以及不同数据存储介质的适配器实现。这样可以将数据访问操作与领域层解耦,同时实现数据存储的切换。

  • 中间件实现: 如果系统使用了中间件,如缓存、消息队列等,你可以在基础架构层实现中间件的具体操作。这有助于将与中间件相关的逻辑隔离在基础架构层中。

  • 事件驱动实现: 如果系统采用了事件驱动的架构,你可以在基础架构层实现事件的发布与订阅机制,以及事件的处理逻辑。

如上图,使用redis提供缓存,使用kafka提供消息队列,使用guava提供事件驱动,仓储层负责实现仓储功能

Application层:

Application层用于组合领域内的服务,形成具体的应用用例。它不包含具体的业务逻辑,而是通过调用领域内的服务来实现功能。在这一层,你可以有以下的组织方式:

  • 应用服务: 应用服务负责处理用户请求,协调领域内的服务,形成具体的用例。每个应用服务通常对应一个用户操作,它们应该是轻量级的,不涉及具体的业务逻辑。
  • DTO(数据传输对象): DTO负责承接前端传入的数据,为领域层转换为对应的业务参数。它们将用户输入的数据进行封装,以便传递给领域层进行处理。
  • 数据转换: 在应用层,你可能需要将领域对象转换为DTO,用于与UI层进行数据交互。数据转换负责将领域对象的数据映射到DTO中,只暴露需要的数据字段。

UI层:

UI层负责展示数据和接收用户输入,它不包含业务逻辑,只是通过调用Application层来触发业务流程。在这一层,主要形式有 api,job和视图页面等等

总结

当我们将三层架构向DDD演进时,我们逐步重塑我们的代码组织,让领域层成为核心,包含实体、值对象、聚合根和领域服务,以最佳方式捕捉业务逻辑和规则。基础架构层负责提供通用能力,如仓储实现、中间件封装等,为领域层提供支持。应用层负责将领域内的服务组合成具体的应用用例,通过调用领域服务实现功能。最后,UI层负责与用户交互,通过调用应用层触发业务流程。这种结构使得不同层次之间的耦合度降低,代码变得更清晰、可维护和可扩展。

在我们演进的过程中,重要的是不仅仅是技术层面的变化,更是对于业务的深入理解和把握。DDD不仅仅是一种架构模式,更是一种用于探索和应对复杂业务的方法论。通过将DDD思想融入我们的架构设计中,我们能够更好地应对日益复杂的业务需求,使得我们的系统更具弹性和适应性,从而为日后面临复杂的业务奠定基础。这虽然充满挑战,但也必将为我们带来更大的成长和收获。
在下一讲主要讲下DDD在实际落地中碰到的问题和解决方案,欢迎关注。