学习了，如果分析的只是，企业内部业务活动，比如专栏制作流程，是不是就不适用了，或者这本身就不是业务建模的一部分？

关于8x flow和四色建模的关系还有些迷糊。是不是可以理解为通过四色建模创建凭证链和合同。然后通过8x flow继续分析合同内的权责关系？但是有个疑惑，四色建模中付款凭证payment已经在凭证中出现了，但是8x flow分析订阅合同的支付请求，支付确认，同样需要对应付款凭证。那么在模型中存在2个payment付款凭证。

如果履约上下文是弹性边界，是否存在一个合同会拆分为多个服务?那实际写代码时如何将这些分散的履约对象合并到一个合同对象中?

老师，想请教下:1.为什么有些履约请求和履约确认是没有凭证的？2.这些履约请求和确认，是转化为调用方法么，方法关联哪些实体呢？

关于这句话有疑问：合同上下文并不是弹性边界，履约上下文才是弹性边界 我觉得合同上下文也是弹性边界。例如专栏订阅合同上下文，对于专栏付款确认有两种履约：预付款和移动支付。 在上面这个例子中，不是可以有三个弹性边界吗，合同和两个履约？

合同确立之前都是领域模型吧？

这样建模完全是现实业务过程的映射，这样服务能力和现实完全吻合了。原来纠结的微服务下数据一致性瞬间不是问题了：本来世界就不是强一致的。

对于其他合同上下文的引用，能不能将其转化为领域系统（比如支付子系统），并与业务部分整合？ 转换为领域系统，当做普通凭证被合同上下文引用，是不是进一步简化了业务建模？少了一个支付上下文。

是否可以这么认为，本文认为，涉及合同/履约的（和财务相关的）才算业务，其他都算领域？有个困惑，大部分业务逻辑中都不会非常明显的和合同直接相关，很多逻辑虽然涉及权责，但也没有明显的合同概念，这些在业务建模的时候如何处理呢？比如，专栏转让这个流程，实际操作中并没有显式的合同出现，这时候加一个“转让合同”这样的三方合同会不会有点硬拗的感觉？另外，很多内部流程并不直接涉及合同和履约，比如仓库内的盘点流程，是仓库内一个例行业务，用来确认仓库内货物是否有丢失和损坏，如果要从合同角度入手建模，会不会显得过于复杂？