限界上下文：统一语言只在单一上下文内成立

领域驱动设计（DDD）的基本思路是给任何模型划出清晰、集中统一的边界，让模型更可能保持正确有效——这套方法在单体架构盛行、系统各部分靠数据库互相集成的年代变得流行，因为那时互相依赖会发展到无法维护的地步，系统一处微小改动可能在别处产生不可预测的副作用，变更风险和部署成本都极高，公司因此完全无法灵活调整自己的IT系统，限界上下文正是为解决这种痛点而生的核心概念。DDD提倡领域专家和开发者统一语言，但关键在于：这种术语统一约定只在同一个限界上下文内部有效，这和许多企业试图为整个公司（或跨多个业务单元）定义一套通用语言的做法正好相反——DDD要求的是术语在单个上下文内保持统一，即使同一个术语在不同上下文里代表完全不同的东西也没关系。以电商公司的”订单”为例：结算上下文里订单指购物车里可随意修改的商品集合；订单履约上下文里订单是收款和发货的明确指令，一旦确立就不可变；库存上下文里订单则完全是另一回事，指向供应商重新订购货物补充库存。”消费者”这个词也一样——订单履约只需要知道消费者身份，发货只需要地址，支付只需要支付详情，各上下文只取自己关心的那个侧面。DDD由此可以帮你定义服务边界：一个上下文可以由一个或多个服务实现，映射不必一对一，但任何一个服务都不能同时跨越多个上下文。