14 | 8X Flow（上）：何为业务？何为领域？

本文示例不是很明白，专栏管理 和 专栏贩售（运营）本来就是两个不同的领域 面向不同的问题域 本来就应该有两套不同的模型 把这两个用领域和业务来区分是否有太绝对了 换句话说 一个业务系统是否只可能有业务和领域两个类别的系统呢？比如用于支撑运营的BI系统、后台运维系统又属于什么呢。

这两个概念从了解DDD开始就有这个疑问，为什么叫domain driven design,而不是business driven design，我们平常都叫业务，从没讲过领域，难道是国外与国内叫法不同，但也不至于啊，给别人介绍DDD时，也会被问到底什么是domain，为什么不是BDD呢？当然，现在DDD被提多了，人们也不像刚开始时那么追问了，顺其自然地接受了，但疑问还在 application service编排业务流程，domain service编排领域，看来是对了，但我们的业务好像都比较简单，是不是只有业务横长，领域纵深的才需要同时业务建模和领域建模呢 当前我们是做票税业务的，接受发票，验真发票，认证抵扣，同步发票(更新由其他系统来的发票状态，也会再同步发票数据到下游系统)；整体看很简单，但复杂在状态同步，首先会多各个业务系统得到状态，比如报销系统来同步发票的报销状态，SAP系统来同步发票记帐状态等等，各个系统都会来写点东西，再把这些发票数据同步到下游系统，但同步下游时就麻烦了，有些客户需要在接受到记帐状态时同步，有些需要在接受到报销状态时同步，各种交叉同步； 从整体系统看似乎只有业务流程，没有领域问题，似乎一个状态机就搞定了，用流程引擎串业务感觉又太重，但现实又复杂得多，看着没法建模，微服务也拆得奇形怪状 像这样流程长而领域浅的系统不知道怎么玩了

"这主要是因为，他并没有区分领域和业务，所以他想解决的问题是对“业务逻辑”的提取。而书中例子多是“领域逻辑”，只不过因为“领域逻辑”更好举例而已" 拆穿了皇帝的新衣啊。。很多时候ddd难理解就是因为书里的例子小而美， 而现实的中的复杂业务系统根本无法那样直觉性的建模

老师好，我的理解，8xflow是不是也是尊重DDD的思想的一种建模方法，比如其实也符合两关联一循环，就像event storming，其实也属于建模方法，但和DDD不是同一个纬度的东西，8xflow和event storming更像是一种东西，只是不同视角的建模方法。 还请老师答疑解惑。

老师，请教个问题，我在应用您的方法时，发现用8xflow的思维方式识别合同，总觉得驴唇不对马嘴。而退而求其次，用四色建模法，发现整个思考过程非常顺畅，这是什么原因造成的呢？ 我看文章最前面有一句话： 「8X Flow 方法是四色法的一种演进。虽然权责追溯仍然是 8X Flow 的核心理念，但比起四色法，8X Flow 更注重通过权责关系，提取业务模式；并通过引入变化点构建可复用的业务模型。所以对于业务平台或业务中台这类系统来说，8X Flow 可谓是量身定制」 这是不是说明，如果是普通的业务系统使用四色建模法就可以了，只有在做更抽象的中台平台等，才适合使用8xflow呢？

有错别字： “因而业务逻辑一般具有运营特性和领域中立性”，其中“运营特性”应该是“运营特定”。 “而领域逻辑源自问题域自身的逻辑，是运行中立而领域特定的”，其中“运行中立”应该是“运营中立”。 编辑仔细校一下啊，篇幅长再有错别字就容易误导了

开放生态模式这个概念，有没有好的现实例子？对这个感觉理解没到位。

在四种业务运营模型中，差异化模式，“对应到软件上，可以将其看作开放生态模式”，这种开放生态模式，该如何构建系统呀？构建不同的系统，由不同的团队开发、维护？

如果只看弹性边界，我觉得面向商家面向运营和面向用户的部分通常有不同的弹性，这是划分服务的标准吗？

关于本章 有个疑问，感觉用这两个角度来思考，还是无法区分需不需要对模型做抽象以便于复用。 1.领域逻辑运营中立性和领域特定性，可不可以就理解为领域逻辑是很具象的？毕竟是特定嘛，那我该不该为它做抽象的建模？可以预知的是卖烤红薯和卖烤土豆应该还是有很多能力是重叠的，抽象这些能力就能供两个领域公用。但是，公用也意味着耦合，不利于独立迭代，是有可能反而影响业务响应速度的。而这个矛盾，识别出领域逻辑的部分这件事好像都不是一个维度。（我们做领域建模时多数时候解决重叠问题域的问题，但今天这堂课的领域概念的区分好像与这个问题无关） 2.业务逻辑具有运营特性和领域中立性，基于经验的不稳定因素，本身就是摸石头过河，想沉淀可以供多个运营模式公用的模型感觉就不靠谱？基于不稳定的事实沉淀稳定的幻想？这个倒是直接说明了，对于业务模型，抽象公用价值会比较有限，快速支持业务的意义更大些。 以上，不知徐老师怎么看？