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

18|中台建模(下):如何寻找可复用的业务模式?

不能对履约请求项进行角色化处理的理由
业务模式复用与功能角度的领域系统
业务模式与领域系统的分离
泛化合同流程以实现业务流程复用
合同流程是业务流程的模板
合同履约隐含的业务流程
从已存在的业务模型中提取业务模式
业务模式需要在业务场景下帮助做出决策
泛化概念与具体实体的平衡
寻找合理的抽象程度
平台能力与应用自主度的概念
中台模式与SaaS模式的区别
中台与平台的差异
思考题
领域系统与业务系统
从合同上下文中提取宏流程
业务模式建模难点
8X Flow建模中台系统
中台建模

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

你好,我是徐昊。今天我们继续学习如何使用 8X Flow 建模中台系统。
在上节课中,我们围绕中台的诸多不同思潮,分析了中台与平台的差异,中台模式与 SaaS 模式的区别。此外,还介绍了平台能力与应用自主度的概念。通过这两个概念,可以帮助我们理解中台在平台能力与应用自主度中取舍的平衡点,就在于“特定场景中的业务模式”,也就是宏流程。
那么作为一门建模课,我们接下来的问题自然就会变成:如何建模宏流程?如何根据得到的宏流程形成完整的中台策略?这也正是我们今天要讨论的问题。

业务模式建模难在哪儿?

通过上节课的学习我们已经知道,宏流程是一种宏观的抽象的流程,需要通过配置与实例化才能变成前台团队需要的具体业务流程。所以宏流程不是流程,宏流程是业务流程的模版。或者说,宏流程是一种可以在不同业务场景下复现的业务模式。
对于业务模式的建模难点主要在于寻找合理的抽象程度。因为业务模式中既有泛化的概念,也有具体的实体。如果泛化概念不够,那么业务模式就会退化为具体的业务功能了;但如果泛化概念太多,则容易引起过度抽象,丧失业务模式的价值。
仍然以出行模式为例,我们可以说出行模式的核心是一种撮合模式,也就是由需求方发起请求,然后从资源池中寻找最为匹配的资源与之对应。但是这种模式又不是泛泛地撮合,而是跟需求方发起需求的时间与位置息息相关的。如下图所示:
确认放弃笔记?
放弃后所记笔记将不保留。
新功能上线,你的历史笔记已初始化为私密笔记,是否一键批量公开?
批量公开的笔记不会为你同步至部落
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线
笔记
复制
AI
  • 深入了解
  • 翻译
    • 英语
    • 中文简体
    • 中文繁体
    • 法语
    • 德语
    • 日语
    • 韩语
    • 俄语
    • 西班牙语
    • 阿拉伯语
  • 解释
  • 总结

本文介绍了如何从8X Flow的合同上下文中提取宏流程,并通过提取出的宏流程构建中台的业务模型。文章指出,业务模式的建模难点在于寻找合理的抽象程度,需要适度泛化以在不同场景下复用,同时避免在具体场景下丧失对业务决策的指导意义。作者强调了从已存在的业务模型中提取业务模式的重要性,以帮助在业务场景下做出决策。此外,文章还提到了在抽象过程中容易出现过度抽象的问题,强调了抽取、重构技巧的重要性。最后,文章提到了从合同上下文中提取宏流程的方法,以及如何在不同业务场景下复用业务模式。整体而言,本文强调了在中台建模中寻找可复用的业务模式的重要性,以及在建模过程中需要注意的难点和技巧。文章内容涉及到了业务建模、合同上下文提取宏流程、中台业务模型构建等技术特点,对于读者快速了解文章概览具有一定的参考价值。

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

全部留言(11)

  • 最新
  • 精选
  • Oops!
    置顶
    思考题,履约请求本来就是合同上下文中的参与角色发起的,如果再将请求项拟人化,相当于把发起请求的动作异步化处理了,这个既不符合事实,也没必要。

    作者回复: nice

    2021-08-12
    3
    8
  • Geek1254
    文中举例的共享单车跟抽象出来的出行合同流程还是不一样吧,单车不涉及行程取消、接驾,但多了归还流程。

    作者回复: 从权责履约看

    2021-08-19
  • keep_curiosity
    思考题:请求是业务流程的一部分,是业务流程进行到特定节点由业务系统触发的。如果把请求也拟人化不仅增加了业务系统对领域系统的依赖,还是因为过度抽象导致业务模式的复用变得低效。

    作者回复: ok

    2021-08-13
  • 狩月
    "所以当我们希望重用业务模式的时候,会将其中的业务部分与领域部分分离,进行业务建模。而如果我们暂时不关心业务模式的复用,那么就可以从功能的角度,将它看成领域系统。" 所以业务建模提炼的是业务模式,领域建模提炼的是业务功能, 那业务建模可以算是一种 meta domain?

    作者回复: 并不是 只是关注点不同

    2021-08-12
  • sam
    思考题:我理解履约请求项应该属于业务系统的参与者,发起方,并不属于业务系统内的概念。有点类似用例中的Actor。所以对履约项请求的角色化就超出了业务系统的范围。

    作者回复: 再想想

    2021-08-12
  • 下弦の月
    因为履约请求项在不同的业务模式下有可能发生变化。比如出现泛化不够,前台实例化用起来很麻烦。或者是有的场景就没这个履约请求。还有可能是某个业务在履约请求前后还有一些特定的步骤要做,要插入新的步骤,导致提取的宏流程要跟着改

    作者回复: 请求的话 泛化太多了

    2021-08-12
  • 张建飞
    撮合模式,这个抽象层次还是太高。B2B B2C C2C O2O也是撮合模式,所以这里的抽象应该是出行撮合
    2022-08-15归属地:中国香港
    2
  • 常文龙
    思考题,思考了将近两个小时,还是得不出结论,非常希望可以得到老师的指点。 譬如条款里,“甲方有权向乙方收取费用”。“收取费用”这件事已经够抽象了吗,我能不能说,“费用是多少”这件事本身就是个变化点?在出租车里,费用收多少是到达终点才能决定的;在顺风车里,费用收多少是邀约的时候确定的(当然中途加价好像也可以);在共享单车里,费用收多少是按照锁车时间确定的; 对应的,每个权都有其凭证,共享单车订单的凭证、顺风车订单的凭证等等,也就是说,这个履约请求本身就有很多“凭证”的可能性,为什么就不能泛化呢?
    2022-03-06
    1
  • 云川
    课后题: 1.请求发起也拟人化,意味着所有都抽象了,失去指导和借鉴意义。 2.请求,需求也抽象,意味着没有具体的需求,那模型失去意义。 3.不管同步还是异步,一定要开始才能有后续的步骤。连开始都没有,所有的讨论都变成无意义的对空。
    2023-12-15归属地:浙江
  • Bravery168
    业务建模既是一门技术,也是艺术~~
    2022-08-06归属地:广东
收起评论
显示
设置
留言
11
收藏
沉浸
阅读
分享
手机端
快捷键
回顶部