DDD | 领域驱动设计 Vs 微服务

一起养成写作习惯！这是我参与「掘金日新计划 · 4 月更文挑战」的第24天，点击查看活动详情。

作为最近相当长一段时间并持续发酵热点的领域驱动设计(Domain Driven Design)和微服务(Microservices)，很多人也许都曾经疑惑过二者的关系。这篇文章简单说明二者之间的关系。

微服务

微服务是一种架构设计风格，具有特定的上下文边界、配置和相关依赖性，使用微服务意味着从松散耦合的服务中创建应用程序。构成的应用程序由几个小服务组成，每个服务代表一个单独的业务目标。它们可以被单独开发并易于维护，之后它们在一个复杂的应用程序中被联合。
微服务之所以受欢迎，是因为它帮助我们避免了整体软件设计、开发、运维等一系列问题，而且我们可以围绕微服务组织我们的团队。

那么，我们怎么来设计拆分微服务呢？前不久看过一篇文章，“You should always design your microservices around your bounded contexts”，是的，你总是应该围绕有限的限界上下文来设计微服务。

领域驱动设计

上文讲到，领域驱动设计是由 Eric Evans 在一本经典的著作《领域驱动设计》提出的，它是针对复杂系统设计的一套软件工程解决的方法。DDD 强调关注点分离与实体之间的联系，比如有限的上下文。

在DDD战略设计中，模型分解是核心思想，那如何分解呢？领域的设计、子域的划分以及限界上下文的组织至关重要。在DDD的限界上下文中，复杂性意味着相互连接、许多不同的数据源、不同的业务目标等等，这跟如何设计微服务不谋而合！

二者关系

领域驱动设计是一种架构设计方法论；而微服务只是一种架构风格，一个大型复杂软件应用是由一个或多个微服务组成的，系统中的各个微服务可被独立部署，各个微服务之间是松耦合的，每个微服务仅关注于完成一件任务并很好地完成该任务。

假如限界上下文之间需要跨进程通信，并形成一种零共享架构，则每个限界上下文就成为了一个微服务。在微服务架构大行其道的当今，我们面临的一个棘手问题是：如何识别和设计微服务？领域驱动的战略设计恰好可以在一定程度上解决此问题。