界限上下文
-
我们怎么去划分界限上下文
我认为通过从业务边界到工作边界再到应用边界这三个层次抽丝剥茧，分别以不同的视角、不同的角色协作来运用对应的设计原则，会是一个可行的识别限界上下文的过程方法。
从业务边界到我们的界限上下文，根据上图的过程展示梳理出来流程：
-
在明确了系统的问题域和业务期望后，开发团队与领域专家经过充分地沟通与交流，可以梳理出主要的业务流程 — 这一阶段需要梳理和输出主要的核心流程图 （N个场景） 最具有业务价值的领域功能
-
业务流程包含了：参与的角色（Who） 业务活动（What） 业务价值（Why） 这里的业务流程不是指的是流程图，而是角色(用户) 活动(操作)的流程 ，所以由业务流程会产生不同的业务场景，比如：用户购买 先登录 或者注册 可以先加入购物车再购买 或者直接购买 加入购物车可以选择优惠卷等方式，然后再进行支付等 里面可能包含了不同的业务场景----如：登陆注册 查找商品 支付等，从业务流程梳理出一个核心的操作流程图和多个业务场景的流程图，
-
现在一个业务流程 -----> 多个业务场景（多个场景的流程图）然后每个场景会对应多种不同的活动，业务活动的描述应该精准地表达领域概念，且通过尽可能简洁的方式进行描述，通常格式为动宾形式。如：收藏商品，购买商品等
可以看到，业务流程是一个由多个用户角色参与的动态过程，而业务场景则是这些用户角色执行业务活动的静态上下文。
-
提取出初步的界限上下文：语义相关系和功能相关性，把活动进行归类
从语义角度去分析业务活动的描述，倘若是相同的语义，可以作为归类的特征。
从功能角度去分析业务活动是否彼此关联和依赖，倘若存在关联和依赖，可以作为归类的特征
-
对于划分活动产生界限上下文会有一些难点：相关联的功能未必是同一个界限上下文，比如：支付和购买 事实上，功能相关性往往会与上下文之间的协作关系有关。由于这种功能相关性恰恰对应了用例之间的包含与扩展关系，它们往往又可成为识别限界上下文边界的关键点。
-
最后的难点就是我们业务边界的划分和边界命名
- 从业务边界到工作边界再到应用边界：到了应用边界，其实主要的就是对业务边界的划分：维度就是我们的重用性和变化，还有我们的技术的选型：不同的语言不同的框架等
其实下面的核心：实现高内聚低耦合：怎么分，怎么合 怎么表示界限上下文的关系
表示界限上下文的关系
领域驱动设计通过上下文映射（Context Map） 来讨论限界上下文之间的协作问题，上下文映射是一种设计手段
上下文的映射有利于我们划清边界
限界上下文的一个核心价值，就是利用边界来约束不同上下文的领域模型，以保证模型的一致性。然而，每个限界上下文都不是独立存在的，多数时候，都需要多个限界上下文通力协作，才能完成一个完整的用例场景。例如，客户之于商品、商品之于订单、订单之于支付，贯穿起来才能完成“购买商品”的核心流程。
两个限界上下文之间的关系是有方向的，领域驱动设计使用两个专门的术语来表述它们：“上游（Upstream）”和“下游（Downstream）”，在上下文映射图中，以 U 代表上游，D 代表下游，理解它们之间的关系，正如理解该术语隐喻的河流，自然是上游产生的变化会影响到下游，反之则不然。故而从上游到下游的关系方向，代表了影响产生的作用力，影响作用力的方向与程序员惯常理解的依赖方向恰恰相反，上游影响了下游，意味着下游依赖于上游。
如果我们通过用例图来帮助识别限界上下文，那么，用例图中的包含用例或扩展用例或许是一个不错的判断上下文协作关系的切入点。选择从包含或扩展关系切入，既可能确定了职责分离的逻辑边界，又可以确定协作关系的方向，这就是用例对领域驱动设计的价值所在了。