全文约字，预计阅读时间13分钟。
导读
继DDD系列文章第4篇：DDD如何做战略设计，做个懂业务的技术后，本篇继续介绍后续步骤，也是DDD里非常重要的限界上下文（英文名BounddContxt，下面简称BC）。BC承上启下了业务分析和技术架构。也是领域模型能够绑定业务知识和技术代码的前提。BC是很什么？如何划分？BC之间如何协作？BC和微服务什么关系？
01
—
什么是BC？
业务流程会伴随很长的生命周期，随着角色的不同和操作的往前推动进入不同的阶段，进而也会产生很多相似的概念。比如围绕订单串联起了电商购物的大部分流程。往往一个业务流程有时候复杂度太大，夹杂着多个有歧义的业务对象和概念。因此需要BC这个更细的粒度来限制这种复杂度。从字面上就知道限界上下文（BC）有两层意思。一是Boundd即有边界的，二是Contxt即业务相关的。BC好比国家：
国家之间有边界，国家有自己的身份主权、法律法规、人文习俗等。国家内部独立运转。一旦出了这个国家，别国的人就不需要遵从了。国家有自己的自身相关的『业务』，业务本身是逻辑自洽的且完整的，一群人为了共同目标形成的一个共同体。
有BC的好处
前面讲业务流程的时候说到了四要素（谁，在什么条件下，做了什么，导致了什么），其实就是业务的上下文信息。日常交流里说到上下文往往指上下文是特定语境的，不同的上下文说出来的同样一句话意思很可能不一样。《茶馆》里有句很著名的台词是这样说的：
宋恩子：我出个不很高明的主意，干脆来个包月，每月一号，按阳历算，你把那点……
吴祥子：那点意思！
宋恩子：对，那点意思送到，你省事，我们也省事！
王利发：那点意思得多少呢？
吴祥子：多年的交情，你看着办！你聪明，还能把那点意思闹成不好意思吗？
这段对话里几处讲到『意思』，但带着不同的语境也表达出了几种不同的含义。划分BC就是要把这种语境固定下来，A语境下的业务不要和B语境的业务混杂到一起，否则就加大了沟通的复杂性，理解起来也很考验每个人的经验，设计和实现的质量必然也会参差不齐。一个BC里的具体业务功能应该准确表达，不带多种语义，不带歧义。反面例子就是中餐烹饪里的某些菜谱，比如『中火，放盐少许，放油适量』等，完全不知道怎么操作，无法量化。
02
—
如何划分BC？
限界上下文划分得怎么样对后续的架构和编码都很重要。但是就像前面说到的例子，BC的划分没有标准答案，其中有很多经验成分，有没有稍微可以借鉴的方法呢？讲方法前还要再强调下意识问题。实际项目中看到很多人认为划分模块这件事不重要，没必要浪费时间，早点开始写代码才最重要。因此模块的划分环节简单了事，全凭经验，拍脑袋。DDD提出把划分BC作为设计中非常重要的一个步骤，这本身就已经很有警示意义了。
划分BC的前提
前篇提到业务流程的拆解和业务功能的拆解。这是划分BC的一个前提。业务需要拆到什么粒度呢？需要知道业务包含哪些用例（UsrCas），也有叫着业务接口，业务能力的。用例拆解到『谁操作了什么』就可以。比如讲线索管理业务需要知道有哪些用例：销售员创建线索、管理员分配线索、销售员修改线索、销售员给线索拨打电话、管理员收回线索等等。尽量把所有的用例找出来，至于说会不会遗漏用例，那就是前一篇业务流程分析的质量问题了，可以借助事件风暴等分析方法识别出所有的业务用例。
划分BC的几个步骤
从领域/业务视角根据业务相关性对用例做归类，垂直划分出多个BC早前都把所有业务放到一个系统，微服务架构后要把业务垂直划分为多个系统，这里的系统跟BC大致相同，后文细说。根据用例的功能相关性或语义相关性进行合并，优先考虑功能相关性。创建订单、拆分订单和支付订单都有『订单』语义上的相关性，但往往把创建订单和拆分订单归为一个订单BC，把支付订单归为单独的支付BC。因为业务上差别很大，各自涉及的业务逻辑和角色也不一样。以技术相关性合并为技术通用BC订单BC和支付BC都需要非功能性需求如监控能力，甚至通用型功能需求如短信通知能力，为了节省建设成本和保持演进的独立性，往往把它们剥离出来，形成对应的技术型BC。以团队粒度对BC大小粒度做裁减这一点即前篇讲到的著名康威定律的实践。如果创建订单和支付订单相关的业务都很小，团队资源也少，分开维护浪费成本，往往把它们合并为一个BC，便于团队分工和效率。反之，如果订单BC业务规模大，涉及团队规模也大，应该把订单BC继续拆解。
案例补充
上面几点都是大面的偏原则性，离实际操作层面还有距离。我主张做一件事时如果没有明确的方法（即可以用演绎法推导完成）时，可先通过归纳法习得必要的经验。下面通过一些例子学习上面的原则，沉淀经验。
有些用例涉及多个名词。如从一个线索转成一个客户。属于线索BC还是客户BC？更多的还是从用例的执行结果看，影响了谁的状态多。这里更多的是一种特殊的客户创建行为，更大概率属于客户BC。再比如用户查询积分，应该属于用户BC还是用户权益相关的BC？同理更应该首先考虑划为后者。多聚焦在用例的名词上面，而不是动词。比如把查询订单，查询商品，查询库存。要不要划为查询BC？首先应该看用例的名词，名词如果是个重要的业务概念，那业务相关性取决于名词。技术因素先入为主。比如发送短信，发送邮件，发送
转载请注明：http://www.0431gb208.com/sjszyzl/3427.html
