如何落地业务建模
徐昊
Thoughtworks 中国区 CTO
24830 人已学习
新⼈⾸单¥68
登录后,你可以任选2讲全文学习
课程目录
已完结/共 32 讲
如何落地业务建模
15
15
1.0x
00:00/00:00
登录|注册

15|8X Flow(中):如何通过模型发现业务系统的变化点?

将参与方和标的物划分入领域边界
寻找违约情况
寻找主要履约项
寻找合同上下文
合同上下文中的聚合关系
凭证在权责履约中的应用
权责履约是最小的业务交互
合同作为业务上下文
业务逻辑建模的有效性
业务逻辑的系统化理解
业务知识的重建与复用的重要性
复用领域功能与构造运营实体的关系
业务逻辑的复用与重建
领域逻辑的稳定性
合同确立之前的建模
其他合同上下文的引用与领域系统的整合
异步模式的建模
弹性边界的切分
反转依赖
业务变化点的发现
业务模式的变化
跨合同上下文的凭证引用
引入第三方支付供应商
建模流程
8X Flow的元模型
履约请求与履约确认的结构
合同的重要性
业务系统的关注点
领域驱动设计的局限性
领域逻辑与业务逻辑的建模
思考题
业务系统中的变化点
凭证角色化建立合同间的关联
使用8X Flow建模
从合同履约理解业务
8X Flow的核心概念
8X Flow学习总结

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

你好,我是徐昊。今天我们继续 8X Flow 的学习。
上节课我们讲到可以将逻辑分为领域逻辑和业务逻辑,而且可以通过不同的方式,分别对领域逻辑和业务逻辑建模。我们也知道了,领域与运营无关,源自某个特定问题域,而业务逻辑与运营相关,大量的业务逻辑源自运营中实践经验的总结。
这个时候我们就需要考虑一个问题:领域逻辑真的能复用吗?我们来分析一下。

领域逻辑真的能复用吗?

由此我们会发现,业务逻辑不如领域逻辑稳定。毕竟业务关注的问题是如何盈利,而不是怎么准确地描述某个问题域。这似乎和我们长久以来的想法相违背:我们希望通过模型精确建模某个问题域,从而实现对该问题域的复用。
然而在商业社会里,复用某个领域,就是围绕这个领域构建能够盈利的运营模式。也就是说,复用某个领域,除了复用领域功能之外,还要构造运营实体。
就像直到今天不会还有人天真地以为,只要复制了淘宝的功能就能再造一个阿里吧!软件总是简单的,但是构造背后的运营实体,以及确立成本合理的运营模式,才是复用的真正重点和难点。换言之,业务知识的重建与复用,才是领域复用的关键
从这个角度来说,领域驱动设计就是天真的谎言。因为它所畅想的美好的复用方式,大多源自技术领域的领域系统,并且不假思索地将这种复用模式推广到业务系统,而忽略了业务系统的运营特定性与领域中立性,这就给我们植入了一个虚假的愿景:通过领域驱动设计,我们可以构造某个领域的通用产品,正如数据库一样,然后就可以忽略业务逻辑,在不同企业间形成复用。
确认放弃笔记?
放弃后所记笔记将不保留。
新功能上线,你的历史笔记已初始化为私密笔记,是否一键批量公开?
批量公开的笔记不会为你同步至部落
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线
笔记
复制
AI
  • 深入了解
  • 翻译
    • 英语
    • 中文简体
    • 中文繁体
    • 法语
    • 德语
    • 日语
    • 韩语
    • 俄语
    • 西班牙语
    • 阿拉伯语
  • 解释
  • 总结

本文讨论了如何通过模型发现业务系统的变化点,主要围绕领域逻辑和业务逻辑的复用问题展开讨论。作者指出领域逻辑相对稳定,而业务逻辑受运营影响较大,因此领域复用需要重点关注业务知识的重建与复用。同时,文章提到了领域驱动设计的理念在实际应用中存在局限性,需要更加关注业务逻辑的系统化理解。此外,作者介绍了财务审计和合同履约作为理解业务逻辑的方法,以及这些方法与8X Flow的核心逻辑的关联。通过对领域逻辑和业务逻辑的讨论,以及对领域驱动设计的批判,引出了对业务系统变化点的探讨。文章内容较为深入,适合对业务系统变化点感兴趣的读者阅读。文章还提到了业务系统中的变化点,以及如何通过反转依赖来引入变化点,从业务本身的结构出发,寻找可能存在的变化点。最后,文章提出了思考题,鼓励读者分享他们的思考和想法。整体而言,本文通过深入的业务逻辑讨论和建模方法的介绍,为读者提供了一种系统化理解业务逻辑的思路。

仅可试看部分内容,如需阅读全部内容,请付费购买文章所属专栏
《如何落地业务建模》
新⼈⾸单¥68
立即购买
登录 后留言

全部留言(22)

  • 最新
  • 精选
  • bird
    听过一门财务课说财务是所有业务的共同语言,任何一家公司的核心业务都能通过三大报表呈现出来。这里说的“合同履约”或者财务上的很多概念思想是可以作为业务建模的“统一语言”的吧

    作者回复: 对

    2021-08-05
    2
    9
  • jack
    学习了,如果分析的只是,企业内部业务活动,比如专栏制作流程,是不是就不适用了,或者这本身就不是业务建模的一部分?

    作者回复: 下一课

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

    作者回复: 8x flow为主

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

    作者回复: 不需要 合同是聚合根即可

    2021-09-30
    2
  • 大大大dvavid
    老师,想请教下:1.为什么有些履约请求和履约确认是没有凭证的?2.这些履约请求和确认,是转化为调用方法么,方法关联哪些实体呢?

    作者回复: 都有有凭证 转化为持久保存的数据

    2021-09-30
  • 梅雪松
    关于这句话有疑问:合同上下文并不是弹性边界,履约上下文才是弹性边界 我觉得合同上下文也是弹性边界。例如专栏订阅合同上下文,对于专栏付款确认有两种履约:预付款和移动支付。 在上面这个例子中,不是可以有三个弹性边界吗,合同和两个履约?

    作者回复: 合同也可以是弹性边界 如果所有履约弹性一致

    2021-08-29
    3
  • 邓志国
    合同确立之前都是领域模型吧?

    作者回复: 也不是

    2021-08-13
  • 邓志国
    这样建模完全是现实业务过程的映射,这样服务能力和现实完全吻合了。原来纠结的微服务下数据一致性瞬间不是问题了:本来世界就不是强一致的。

    作者回复: 领域系统大多强一致 业务不一定

    2021-08-13
  • 顿晓
    对于其他合同上下文的引用,能不能将其转化为领域系统(比如支付子系统),并与业务部分整合? 转换为领域系统,当做普通凭证被合同上下文引用,是不是进一步简化了业务建模?少了一个支付上下文。

    作者回复: 如果只需要功能 不需要凭证可以 上下文没少 只是少个业务上下文 领域不是还多一个

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

    作者回复: 请回到现实中看。在想软件是怎么会之前,看看现实是怎么回事

    2021-08-07
收起评论
显示
设置
留言
22
收藏
沉浸
阅读
分享
手机端
快捷键
回顶部