基于领域的归类，我们大体上有了相应的领域划分，我们将具体的领域归类为核心域和支撑域以及通用域之后。那么下一步就应该基于具体的领域进行相应的限界上下文的划分了。
首先限界上下文在后面具体的开发中，其实就对应一个微服务。既一个限界上下文，就应该有对应的微服务做为落地。而且这个微服务不光是代码层面的，数据层面也可以是相对独立的。
我们继续来探讨限界上下文和领域的关系，一般来讲，一个领域可以有一个甚至多个限界上下文来进行管理。而且该领域的实体对象维护（增删改）都仅由基于这个领域而划分出来的限界上下文来进行操作维护。
但需要注意这些限界上下文中所涉及到的实体对象可以不光只是这个领域的实体对象，也有可能是其他领域的实体对象。但对于其他领域的实体对象，这个限界上下文并不对这些实体对象进行维护职责，这个非常重要。在这个界限上下文中，一些功能职责可能需要这些实体对象做为接口的输入参数对象而已。一个例子来概述：就是A 领域 诞生了 A‘ 限界上下文，那么 A‘ 肯定要有维护A领域的实体对象的功能和方法，但 A‘ 可能也需要涉及 B领域的实体对象，但仅做为一些方法的参数，而B 领域这些对象，对于 A‘ 这个限界上下文来说，就是只读的不变的。
划分限界上下文时，同时我们也需要将这个限界上下文的一些功能职责梳理出来。对于功能职责总体而言限界上下文的功能肯定是围绕该限界上下文维护的领域对象的业务接口，但除此以外我们还会发现会有两个比较特殊的情况出现：
第一种情况是我们会发现有一类需求用例是需要跨多个领域，并需要将多个领域串联起来进行联动才能完成相应的业务用例。比如支付用例，如果就有这样流程逻辑，支付时用户可以选择用商户发放给用户的红包进行金额抵扣。针对这个流程逻辑，我们对商户发放的红包和支付订单一般来说不会设计成同一个领域，所以维护这两个领域实体对象的限界上下文也肯定不是同一个，所以这个流程是多个领域和多个限界上下文共同串联才能支撑起来的。
第二种情况就是在分析限界上下文除了自己维护的领域实体对象外，可能还跨别的领域实体对象（本文前面例举探讨过这个问题），实际上这个限界上下文既然依赖外部领域（我们将限界上下文不能维护的领域但需要依赖的领域称为外部领域），也就必然在业务流程上反应了两个限界上下文的调用依赖性。还是拿第一种情况的案例来例举：支付流程，需要红包抵扣。那么这里面有营销域（红包）和支付域（支付）。那么维护红包的状态和维护支付订单的状态也应该分别交给了营销限界上下文和支付限界上下文。这里营销限界上下文可能会发现，我的红包状态变更，需要依赖于你支付域，需要支付域的订单信息。所以这里面就存在一个时序和依赖关系。
为了验证用例的完整性以及，我们一般是通过用例通过时序图调用图来进行相关。时序图中的顶部节点是我们前面设计划分好的限界上下文，通过这样的限界上下文的串联，我们可以将一个复杂的用例，完整的表示出来。而且在业务和限界上下文的串联我们会逐渐的清晰 一个限界上下文所拥有的内部领域实体对象和依赖的外部领域实体对象，以及相应的功能智能。那么我们就可以形成以下这样一个限界上下文的范围图
网友评论