16｜8X Flow（下）：多于一个例子

该思维导图由 AI 生成，仅供参考

徐八叉在文章《8X Flow（下）——多于一个例子》中详细介绍了如何使用8X Flow进行业务建模。他首先讨论了在合同签订之前的业务逻辑建模方法，提出了以事件建模法使用8X Flow的思路。通过一个买菜的例子，阐述了从邀请投标到履约的全生命周期，并指出可以通过头脑风暴等方式将8X Flow的建模过程改造为共创工作坊。文章还探讨了合同之前的上下文与合同上下文的关系，强调了它们应该具有不同的弹性边界，并指出合同前的上下文是系统另一个重要变化点。最后，作者强调了投标邀请和投标虽然不是履约项，但也具有Request-Confirmation的结构，从而证明了异步在业务的交互中无处不在。文章通过具体案例和理论分析，深入浅出地介绍了8X Flow的建模方法和相关概念，为读者提供了深入理解和应用8X Flow的思路和方法。文章还讨论了在系统中不包含合同的情况下，如何使用权责履约对内部绩效系统进行建模，以及领域系统和工具系统的建模方法。整体而言，本文为读者提供了深入理解和应用8X Flow的思路和方法，对于业务建模和系统分析具有重要的参考价值。 通过这三节课，我们完整学习了8X Flow建模法。我们首先区分了什么是业务逻辑，什么是领域逻辑。从合同履约入手，通过履约项和合同上下文建立业务模型。 今天，我们又介绍了合同之前的上下文，也就是渠道上下文。并解释了为何公司内的绩效管理也可以通过协议与履约的方式进行建模。 纵观8X Flow的建模方法，它的出发点是完全以业务为核心，构造可以支持业务的业务系统。并通过对业务模式的建模，将不同的领域逻辑复用到业务模式中。 总之，我们不要老是抱怨业务逻辑不易理解、变来变去的。事实上，业务逻辑是最简单，也是最理性的逻辑：多赚钱少花钱，规避法律风险，提供合规审计。要知道这套逻辑，业务方不光要跟你讲，也会跟投资人、股东讲，还会跟审计、法务讲，所以绝对是经过了千锤百炼，可以放心使用。 思考题：通过系统中的变化点，我们可以如何来建模中台系统？