DDD应用于微服务划分

1 介绍引入

• 随着互联网应用的发展，在敏捷快速迭代、高可用、高性能、高并发等方面要求越来越高，传统的SOA分布式架构并不适合这种场景，互联网最新流行且最佳的实践方式就是微服务化。

• 而微服务的首要问题是微服务如何拆分。现在很多的微服务开发团队在设计和实现微服务的时候觉得只要把原来的单体拆小，就是微服务了。但是这不一定是正确的微服务，可能只是一个拆小的小单体。而这种拆分真的能够给我们带来微服务架构的那些好处吗？

• 随着熟悉“领域驱动设计”方法的工程师发现，由于DDD可以有效的从业务视角对软件系统进行拆解，并且DDD特别契合微服务一个特征：围绕业务能力构建。这样搭建的微服务系统比较合理并且高内聚低耦合。

  下面从DDD的方法论上探讨系统如何拆分之两种方式：

1.1 聚合根

• 从广义上讲，领域（Domain）即是一个组织所做的事情以及其中所包含的一切。每个组织都有它自己的业务范围和做事方式。这个业务范围以及在其中所进行的活动便是领域。
• 领域驱动设计一个重要的概念就是聚合根。聚合可以由单个实体组成，也可以由一组实体和值对象组成。聚合就是一组相关对象的集合。每个集合都有一个根和一个边界。边界定义了聚合的内部都有什么。根是聚合中所包含的一个特定实体。在聚合中，根是唯一允许外部对象保持对它的应用的元素，而边界内部的对象之间则可以互相应用。
• 从聚合根的特性来看，它是业务系统的一层边界，识别了聚合根后，在重构拆分微服务时，很容易从一个应用迁移到另一个应用。
  

1.2 限界上下文

• 限界上下文是一个显式的边界，领域模型便存在于这个边界之内。创建边界的原因在于，每一个模型概念，包括它的属性和操作，在边界之内都具有特殊的含义。一个限界上下文并不是只包含领域模型。诚然，模型是限界上下文的主要“公民”。但是，限界上下文并不只局限于容纳模型，它通常标定了一个系统、一个应用程序或者一种业务服务。由此可见，提炼限界上下文的方法也可以作为微服务的拆分。限界上下文比聚合根是在一个更大的范围限定的服务的边界。
• 我们如何认为上下文边界的划分是合理的，通常情况下，如果你在不同的上下文中看到了完全相同的对象，这通常意味着你的模型是错误的或者上下文划分不合理。这时候就需要调整上下文或者识别出相识对象的细微区别。

抽象图：

一个具体例子图：

2 总结

经过理论的严密推理和大量实践项目的验证，业界绝大多数人士认为DDD是当前软件工程业界设计微服务的最佳实践。其中的很多理念和方法可以用来指导微服务拆分和设计，并且能促进企业软件开发能力的发展，提高开发质量和效率。