DDD与微服务是可以相通的，其关键在于Bounded Context。
分布式系统的定义
在谈论这个之前，我们需要就什么是分布式系统达成一致。在我看来，判断一个系统是否是分布式的，其标准是看系统中是否存在跨进程通信。是进程决定了协作与通信的方式，从而引申出两种具有本质区别的编程模型：
- 进程内编程模型
- 跨进程编程模型
它们之间的区别在于组件之间的调用方式。进程内的组件调用是非常简单的，就Java而言，各个驻留于同一个JVM的对象与变量都放在堆内存或者栈内存中，对象的调用（包括方法的调用）就是一种内存的寻址。Java语言通过new关键字创建实例，从而获得该实例的指针，以便于对该实例的属性与方法进行调用。
跨进程组件之间的调用方式与进程内调用有着本质的。虽然跨进程通信机制存在各种不同的实现，但它们要考量的因素都是相同的，需要考虑：
- 进程间的通信协议
- 如何寻址
- 消息的序列化与反序列化
除此之外，在资源管理、事务一致性以及部署方面，都会因为跨进程通信的原因而产生巨大的差别。
显然，跨进程通信固有的复杂度带来了编程模型的改变，但它能够更加有效地利用硬件资源，却是分布式系统的主要目标。因此，在IT发展的当前历史背景下，我们将进程作为边界来定义分布式系统是非常有意义的。
说明：不同的语言平台，进程的概念有细微差别，通信机制自然也有所不同。Java进程等同于操作系统的进程，但Erlang与Go的进程概念则不相同，要更加轻量级。
跨进程组件之间的调用方式其实是对通信机制的一种抽象，它其实又包含了：
- 进程间通信机制（如共享内存、管道、Socket）
- 结构化通信机制（如RPC）
- 中间件通信机制（分布式对象如CORBA、组件中间件如EJB、消息中间件、面向服务与REST）
讨论C4模型的Container
Simon Brown提出了自己的C4模型，如下图所示：
我们对Container的划分，可以将进程作为划分的边界，即我认为的“物理边界”。所以Container在架构中除了可以作为逻辑视图的组成元素之外，也可以视为物理视图的一部分。
无独有偶，Alistair Cockburn提出的六边形架构（又名port-adapter模式）在边界含义上与Container是与之呼应的。下图中外部六边形的边界就是一个物理边界，按照之前的分析，我们可以将其视为进程边界。
微服务与Bounded Context
微服务作为一个可以独立部署的微小服务，天生就是一个在物理上隔离的自治服务。从物理视图的角度看，一个微服务就是C4模型中的Container，也就是六边形架构中的六边形。如果我们将六边形架构与DDD的Bounded Context对应起来，那么就可以引入DDD的战略设计来划分服务边界，从而帮助我们进行微服务设计了。
一个典型的Bounded Context，可以具有自己的领域模型，访问专有的数据库，且可以引入“依赖注入”来满足Uncle Bob所谓的Clean Architecture思想。下图所示的Bounded Context的架构，不正是可以表现为一个微服务吗？
Context Map对微服务的阐释
思考DDD中的Bounded Context，可以重点把握以下两点：
- Bounded Context与Domain之间的关系
- Context Map
倘若我们认为Bounded Context与Domain之间存在对应关系，就说明可以从业务架构的层面来设计微服务。通过用例、通用语言或者其他手段，都可以帮助我们识别Bounded Context，进而得到相对合理的服务边界。
若要判断微服务的设计是否合理，则可以通过DDD的Context Map进一步验证和判别Bounded Context的划分，并理清楚它们之间的关系。
Eric Evans在DDD一书中列出了九种Context Map，基本上可以归类为：
- 团队之间的协作方式
- 进程之间的集成方式
为什么说Bounded Context之间的关系可以理解为是团队之间的协作方式呢？理论根据来自康威定律，即：
设计一个系统（此处泛指更广泛的系统，而不仅仅是信息系统）的任何组织都必然会产生一个其结构是该组织通信结构副本的设计。
一个Bounded Context可能会映射到一个开发团队，所以讨论Bounded Context之间的关系，也可以视为是讨论团队之间的关系。至于进程之间的集成方式，无论是引入ACL（防腐层）还是OHS（开放主机服务），目的都是在实现进程间通信的同时，更好地做到Bounded Context之间的松散耦合。以微服务观之，就是要满足服务边界足够的自治性。
故而当DDD遇到微服务，其实有许多玄妙的相似之处值得深究。它们之间或许可以碰撞出感情的火花，也未可知呢。
