15|8X Flow(中):如何通过模型发现业务系统的变化点?
徐昊
该思维导图由 AI 生成,仅供参考
你好,我是徐昊。今天我们继续 8X Flow 的学习。
上节课我们讲到可以将逻辑分为领域逻辑和业务逻辑,而且可以通过不同的方式,分别对领域逻辑和业务逻辑建模。我们也知道了,领域与运营无关,源自某个特定问题域,而业务逻辑与运营相关,大量的业务逻辑源自运营中实践经验的总结。
这个时候我们就需要考虑一个问题:领域逻辑真的能复用吗?我们来分析一下。
领域逻辑真的能复用吗?
由此我们会发现,业务逻辑不如领域逻辑稳定。毕竟业务关注的问题是如何盈利,而不是怎么准确地描述某个问题域。这似乎和我们长久以来的想法相违背:我们希望通过模型精确建模某个问题域,从而实现对该问题域的复用。
然而在商业社会里,复用某个领域,就是围绕这个领域构建能够盈利的运营模式。也就是说,复用某个领域,除了复用领域功能之外,还要构造运营实体。
就像直到今天不会还有人天真地以为,只要复制了淘宝的功能就能再造一个阿里吧!软件总是简单的,但是构造背后的运营实体,以及确立成本合理的运营模式,才是复用的真正重点和难点。换言之,业务知识的重建与复用,才是领域复用的关键。
从这个角度来说,领域驱动设计就是天真的谎言。因为它所畅想的美好的复用方式,大多源自技术领域的领域系统,并且不假思索地将这种复用模式推广到业务系统,而忽略了业务系统的运营特定性与领域中立性,这就给我们植入了一个虚假的愿景:通过领域驱动设计,我们可以构造某个领域的通用产品,正如数据库一样,然后就可以忽略业务逻辑,在不同企业间形成复用。
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线
笔记
复制
AI
- 深入了解
- 翻译
- 解释
- 总结
本文讨论了如何通过模型发现业务系统的变化点,主要围绕领域逻辑和业务逻辑的复用问题展开讨论。作者指出领域逻辑相对稳定,而业务逻辑受运营影响较大,因此领域复用需要重点关注业务知识的重建与复用。同时,文章提到了领域驱动设计的理念在实际应用中存在局限性,需要更加关注业务逻辑的系统化理解。此外,作者介绍了财务审计和合同履约作为理解业务逻辑的方法,以及这些方法与8X Flow的核心逻辑的关联。通过对领域逻辑和业务逻辑的讨论,以及对领域驱动设计的批判,引出了对业务系统变化点的探讨。文章内容较为深入,适合对业务系统变化点感兴趣的读者阅读。文章还提到了业务系统中的变化点,以及如何通过反转依赖来引入变化点,从业务本身的结构出发,寻找可能存在的变化点。最后,文章提出了思考题,鼓励读者分享他们的思考和想法。整体而言,本文通过深入的业务逻辑讨论和建模方法的介绍,为读者提供了一种系统化理解业务逻辑的思路。
仅可试看部分内容,如需阅读全部内容,请付费购买文章所属专栏
《如何落地业务建模》,新⼈⾸单¥68
《如何落地业务建模》,新⼈⾸单¥68
立即购买
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
登录 后留言
全部留言(22)
- 最新
- 精选
- bird听过一门财务课说财务是所有业务的共同语言,任何一家公司的核心业务都能通过三大报表呈现出来。这里说的“合同履约”或者财务上的很多概念思想是可以作为业务建模的“统一语言”的吧
作者回复: 对
2021-08-0529 - jack学习了,如果分析的只是,企业内部业务活动,比如专栏制作流程,是不是就不适用了,或者这本身就不是业务建模的一部分?
作者回复: 下一课
2021-08-053 - 大大大dvavid关于8x flow和四色建模的关系还有些迷糊。是不是可以理解为通过四色建模创建凭证链和合同。然后通过8x flow继续分析合同内的权责关系?但是有个疑惑,四色建模中付款凭证payment已经在凭证中出现了,但是8x flow分析订阅合同的支付请求,支付确认,同样需要对应付款凭证。那么在模型中存在2个payment付款凭证。
作者回复: 8x flow为主
2021-10-261 - Z.G如果履约上下文是弹性边界,是否存在一个合同会拆分为多个服务?那实际写代码时如何将这些分散的履约对象合并到一个合同对象中?
作者回复: 不需要 合同是聚合根即可
2021-09-302 - 大大大dvavid老师,想请教下:1.为什么有些履约请求和履约确认是没有凭证的?2.这些履约请求和确认,是转化为调用方法么,方法关联哪些实体呢?
作者回复: 都有有凭证 转化为持久保存的数据
2021-09-30 - 梅雪松关于这句话有疑问:合同上下文并不是弹性边界,履约上下文才是弹性边界 我觉得合同上下文也是弹性边界。例如专栏订阅合同上下文,对于专栏付款确认有两种履约:预付款和移动支付。 在上面这个例子中,不是可以有三个弹性边界吗,合同和两个履约?
作者回复: 合同也可以是弹性边界 如果所有履约弹性一致
2021-08-293 - 邓志国合同确立之前都是领域模型吧?
作者回复: 也不是
2021-08-13 - 邓志国这样建模完全是现实业务过程的映射,这样服务能力和现实完全吻合了。原来纠结的微服务下数据一致性瞬间不是问题了:本来世界就不是强一致的。
作者回复: 领域系统大多强一致 业务不一定
2021-08-13 - 顿晓对于其他合同上下文的引用,能不能将其转化为领域系统(比如支付子系统),并与业务部分整合? 转换为领域系统,当做普通凭证被合同上下文引用,是不是进一步简化了业务建模?少了一个支付上下文。
作者回复: 如果只需要功能 不需要凭证可以 上下文没少 只是少个业务上下文 领域不是还多一个
2021-08-11 - Oops!是否可以这么认为,本文认为,涉及合同/履约的(和财务相关的)才算业务,其他都算领域?有个困惑,大部分业务逻辑中都不会非常明显的和合同直接相关,很多逻辑虽然涉及权责,但也没有明显的合同概念,这些在业务建模的时候如何处理呢?比如,专栏转让这个流程,实际操作中并没有显式的合同出现,这时候加一个“转让合同”这样的三方合同会不会有点硬拗的感觉?另外,很多内部流程并不直接涉及合同和履约,比如仓库内的盘点流程,是仓库内一个例行业务,用来确认仓库内货物是否有丢失和损坏,如果要从合同角度入手建模,会不会显得过于复杂?
作者回复: 请回到现实中看。在想软件是怎么会之前,看看现实是怎么回事
2021-08-07
收起评论