学习视频来源：DDD独家秘籍视频合集 https://space.bilibili.com/24690212/channel/collectiondetail?sid=1940048&ctype=0

DDD与微服务的关系

1. DDD可以用微服务实现，也可以不用微服务实现

DDD是一套方法论，我们用它可以设计出领域模型，领域模型可以指导程序员去写代码实现功能，但DDD并没有指定一定要用什么样的架构实现。它的实现架构是在不断演变的，它可以使用微服务来实现，也可以不用微服务来实现。DDD是在2003年提出的，微服务在2014年提出的，所以在微服务出现之前，DDD就已经用其他的架构实现了。

2. DDD是微服务拆分的必须参考项之一

不能将同一个上下文的功能分拆到不同的微服务中。 在实践过微服务之后，人们发现微服务的服务力度比传统的SOA力度更小，那就涉及到更多的要把哪些功能分拆到哪些微服务的问题。人们又发现领域驱动设计得到的限界上下文，正好可以回答这个问题。如果要做微服务设计，就必须参考领域驱动设计得到的限界上下文，否则就很可能形成一个分布式大泥球。

拆分方案
方案1： 把多个限界上下文放到同一个微服务中，这样做没有问题

方案2：把多个限界上下文分别放到不同的微服务中，这样做也没有问题。

方案3：把同一个限界上下文，放到不同的微服务中，这样做有问题。
这样做会导致两个微服务之间的关系非常的紧密，二者之间需要网络通信。如果微服务架构大量存在这种场景，最终它就会形成一个分布式大泥球，难以维护，还不如使用单体架构。

3. 微服务架构还需要考虑别的因素

DDD是微服务拆分的必须参考项之一，但不是全部。其他因素比如：

• 伸缩性边界
  这是微服务架构的初衷。
• 团队结构
• 遗留系统

总结

领域驱动设计得到的限界上下文是微服务拆分的必须参考项之一，拆分错的话，可能会形成分布式大泥球，但并不是唯一因素。