限界上下文的意义

经过最近10多年的演进，我们在如何支撑一个组织的规模化上达成了一些基本的共识。我们知道微服务架构（Microservices）能够帮助我们把成百上千的工程师们组织起来，而小团队的自组织性是至关重要的。我们也逐步就如何能够在技术和业务团队之间明确沟通“架构”这个难题上找到了DDD。那么DDD和微服务架构的关系是什么呢？很多人会提到限界上下文（Bounded Context）。

我曾经就这个话题专门撰文一篇（DDD&Microservices）。一个限界上下文封装了一个相对独立子领域的领域模型和服务。限界上下文地图描述了各个子领域之间的集成调用关系。这个定义某种意义上和我们的微服务划分不谋而合：以提供业务能力为导向的、自治的、独立部署单元。所以虽然我们不能百分百依据限界上下文划分服务，但限界上下文，或者说是DDD，绝对是我们设计微服务架构的重要方法之一。

如果我们再追溯到DDD的战略设计，我们会发现在问题域上，DDD通过子问题域（subdomain）的划分就已经进行了针对业务能力的分解，而限界上下文在解决方案域中完成了进一步分解。当然我们不能完全认为子问题域和限界上下文有严格意义上的一对一关系，但大多数情况下一个子问题域是会被设计成一个或多个限界上下文的。子域subdomain和限界上下文某种意义上是互相印证的，重点在区分问题域和解决方案域，这是落地DDD最困难的地方，也是判断一个架构师能力进阶的分水岭。