下载掌阅APP，畅读海量书库
立即打开
领域驱动的设计思想和方法可以应用到多种类型的系统开发过程中。无论采用哪一种应用方式，对于DDD而言，我们都需要开展面向领域的战略设计和战术设计。通用语言、限界上下文、各种领域模型对象、涉及多对象交互的领域服务、处理状态转变的领域事件、提供数据访问的资源库以及实现业务外观的应用服务等都是需要实现的组件。在本节中，我们将分别从单体架构、微服务架构以及中台架构这三大类目前主流的架构体系出发探讨DDD的应用方式。
在软件技术发展的很长一段时间内，应用系统都表现为一种单体系统。时至今日，很多单体系统仍然在一些行业和组织中被开发及维护。所谓单体系统，简单讲就是把一个系统所涉及的各个组件都打包成一个一体化结构并进行部署和运行。在Java EE领域，这种一体化结构很多时候就表现为一个WAR或JAR包，而部署和运行的环境就是以Tomcat为代表的各种应用服务器。
对于单体系统而言，所有DDD组件都位于同一个应用程序中，但我们仍然可以从逻辑上对限界上下文进行拆分。这样各个限界上下文就是一个个模块，如图1-14所示。
如图1-14所示，在单体系统中DDD的应用有几个显著的特点。首先，单体系统的数据库通常只有一个，所以资源库的实现相对简单，不需要考虑分布式环境下的数据一致性问题。然后，因为所有的代码都运行在同一个服务器实例中，所以诸如领域事件的实现过程也就不需要考虑跨JVM的消息通信机制。
图1-14 单体系统的DDD应用方式
微服务架构这个术语在最近几年的软件开发方法中非常热门，它把一种特定的软件应用设计方法描述为构建一系列能够独立部署的服务套件。
顾名思义，微服务区别于其他服务体系的关键在于“微”这个特性。“微”是小的同义词，所以容易让人联想到微服务都是小型的服务，这是微服务的第一个特性。然而，业界并没有给出一个关于微服务大小的具体划分规则和标准。因此，在基于DDD实现微服务架构时，我们可以按照限界上下文的粒度来确定微服务的大小。图1-15展示了限界上下文与微服务之间的对应关系。
图1-15 微服务系统的DDD应用方式
在图1-15中，我们注意到每一个微服务都是一个独立的应用程序实例，且都使用了独立的数据库。所以，在单体系统中不需要考虑的数据一致性问题以及跨JVM的领域事件发布和消费机制，在微服务架构中就变成了技术实现上的挑战，开发人员需要引入相应的架构模式和工具来完成各个限界上下文之间的高效集成。
当我们采用微服务架构时，服务的边界以及拆分方式同样是架构设计时的核心问题。针对这一问题，DDD和微服务采用的设计思想与工程实践是完全一致的。事实上，正是微服务架构的兴起，才促进了目前DDD的广泛应用。
另外，微服务之间只有通过协作和交互才能构成完整的服务体系，而这种协作和交互机制也是微服务区别于其他服务体系的一个主要方面。在微服务架构中，服务之间通过注册中心实现注册和发现，并通过API网关实现服务路由和访问控制，如图1-16所示。
图1-16 微服务架构中的注册中心和API网关
中台这一概念来源于阿里的中台战略，目的是构建符合数字时代的、更具创新性和灵活性的“大中台+小前台”的业务组织方式。中台通常分成业务中台和数据中台两大类别，这里讨论的是业务中台。
中台和微服务架构并不是同一层面的事物，可以简单认为微服务是构建中台的一种组件化实现手段。在中台架构中，每一个中台都由一组微服务构成。因此，我们可以在微服务架构的基础上添加对中台架构的描述，如图1-17所示。
图1-17 中台架构的DDD应用方式
与任何一种软件设计和开发的方法论一样，领域驱动设计并不适合所有业务系统的开发。在采用这种方法之前，我们需要结合自身正在开发的业务系统来分析应用方式。关于这一点，我们会在最后一章讨论DDD实践方法时进一步展开讨论。