从实际业务中来，到落地业务建模中去

图片来源：pexels.com

做了这么多年项目，不知道你有没有发现一个有趣的现象：有时候面对同一个问题，当我们对它的定义不同，往往最终解决方案的差异也会非常大。

拿我司之前的一个需求来说，客户要求将一份带有大量文字介绍的图片报告转换成 PDF 格式，以方便用户下载。但由于每张图片具体说明信息不同，所以难免会出现一些排版格式的错误。

于是，我们项目组的一位技术骨干提出了一个看似“完美”的解决方案：

利用后台渲染技术，在服务器端的浏览器进程中渲染页面，再将渲染好的页面通过浏览器后台进程转存为 PDF 文档，并通过云端的大规模存储服务缓存；

另外，为了应对突发巨量下载的可能性，还得用上当时最先进的云计算，构造一组后台渲染集群，并根据下载量的大小，利用云计算的弹性动态调整集群的大小。

可以看出，他是这样定义该问题的：PDF 中保留的信息样式，要和用户在浏览器中看到的一致。

方法是没错，但貌似看起来过于复杂？现在我们换个思路，解决这个问题前，先搞清楚客户为什么想保留图片的文字说明？一问才知道，图片上的是版权信息声明，保留是为了避免法务纠纷。

这时候，该问题的定义自然变成了：PDF 中确实要保留图片的版权信息，但读者只用知道其存在，并不一定要直接阅读它。

从这个定义出发，最终的解决方案就简单多了：当图片说明文字超过一定字数，直接选择一个很小的字号，以保证信息留存在 PDF 中即可。实现方案，也就只是一条 if 语句的事儿。

从一个后台渲染集群到一条 if 语句，两者的成本和实施难度的差距不用我多说。看到没，这就是有效定义问题的重要性。

而要想做到有效定义问题，首先得从业务实际出发，并尽力在业务中寻找简化问题的可能性，然后在技术中寻找对应的解决方案。这个过程，也叫做业务建模。

在上述例子中，我甚至还没有动用任何建模手段，只靠澄清了真正诉求，就极大地简化了解决方案。但在日常开发里，各个因素都可能极大提高问题的复杂度，所以除了清晰地理解业务诉求之外，更加需要我们通过建模的方式对这种复杂度进行简化与精炼。

作为业务建模的践行者和创新者，我发现平时不少人都有没搞清问题定义而去舍近求远做事情的困扰，所以，我和极客时间合作推出了《如何落地业务建模》专栏。在专栏中，我会系统讲解建模所掌握的多种方法、原则，以云时代时间轴为界，带你清晰定义业务问题，掌握在架构下，业务建模的最佳实践以及实现模式。

跟我学完这门课，相信你能快速重构建模技能，掌握业务建模精髓和切实有效的落地方法论。无论是作为帮你高效搞定项目的方法，还是一种思维的训练法，业务建模都非常值得你花时间去琢磨。

秒杀+口令「jianmo666」立省 ¥80

到手六折，仅限前 50 人

我是谁？

我是徐昊（八叉），ThoughtWorks 全球技术策略顾问、中国区首席技术官（CTO），ThoughtWorks 技术雷达编撰人。谈话节目「八叉说」作者。

同时我也是北京 Java 用户组（ BJUG：Beijing Java User Group）和 Agile China 主要创始人之一。从 2003 年起开始实践极限编程等敏捷方法，并多次以敏捷教练的角色帮助国内外多个团队实施极限编程，提高编码迭代效率。

此外，我也曾主持 ThoughtWorks 中国区技术特种兵小巨人管培计划，为行业输送了多位技术带头人。近年提炼了大规模工程实践方法 SEELE ，以进一步提升研发团队的工作效能。

如何学习业务建模？

业务建模的方法有很多种，它的吊诡之处就在于，使用的难度并不在于建模本身。无论是哪种建模方法，你总能按照书里教程中的例子，照猫画虎地做个七七八八。

但，业务建模存在两个真正的难点：

清晰地定义业务问题，并让所有干系人都接受你对业务问题的定义；
在特定架构的约束下，将模型实现出来。

为了帮你搞定这两点，以及更好地了解和掌握建模的最终落地，我在每一讲内容中，都按照步骤展示了很多领域模型，方便大家在阅读中能够清晰梳理整体脉络，同时也可以保存下来，随时查看复习。

下面这个就运用了四色建模法，以一个极客时间的专栏生产和售卖为例，按照关键数据项间的关联，将模型连载一起，稍加润色，补充描述对象，从而得到了如下的领域模型：

回归主题，课程分为两大板块：

一、旧约：“前云时代”的领域驱动设计

这部分是过去十五年“前云时代”，我们对领域驱动设计应用的总结与提炼，因而称为“旧约”。

首先，我会为你介绍领域驱动设计方法。作为一种建模方法，虽不是那么出色，然而却能够在如何引领需求发掘，如何建立沟通反馈，如何与业务方共建模型等问题上，提供到一套出色的框架。

而后，我会为你介绍在多层架构成为主流架构选择的时代中，领域驱动设计在模型实现上遇到了哪些挑战，以及如何应对，帮助我们理解架构约束会对模型带来何种影响。

最后我会介绍四种建模方法，分别是：催化剂法、角色-目标-实体法、事件风暴与四色法，以弥补领域设计在建模能力上的缺陷。

二、新约：“云时代”的业务建模

如今，云时代彻底改变了我们构造软件的方式，微服务、中台、软件的 SaaS 化都是这一影响的体现。新的架构约束会极大影响我们业务建模的方法，但同时也大大扩展了业务建模的内涵。

我会来和你聊聊云到底带来了哪些观念上的改变，它具体的颠覆性体现在什么地方，以及对我们构造业务系统有多少影响。

其次，我会介绍一种由我发明的业务建模方法 8X Flow 法，用于解决微服务、分布式事务为主导的架构风格中的业务建模问题。这个方法同样可以用于构建中台系统，也是我司目前用于中台建模的主要方法。

最后，我会介绍另一个同样是我发明的用于 SaaS 化业务建模的方法：魔球服务建模法（Money Ball Offering Modeling）一种从运营角度出发，构造SaaS化服务的实用方法。

还有很多具体内容，可以看看课程目录。

我的粉丝仍有专属福利：

拼团 + 秒杀口令「jianmo666」
立省 ¥80，仅限前 50 人！

订阅后生成海报发给好友，

每成功邀请 1 位好友，可得 ¥20 返现。

从实际业务中来，到落地业务建模中去相关推荐

【ChatGPT】ChatGPT 在电商B端业务中的应用落地场景产品化思考
ChatGPT 在电商B端业务中的应用落地场景产品化思考文章目录 ChatGPT 在电商B端业务中的应用落地场景产品化思考电商B端业务的本质思考电商B端业务的本质特征 1. 交易规模较大 2. ...
如何落地业务建模(1) 业务建模、DDD
业务建模解决问题还是定义问题业务建模首先是一个定义问题的方法,其次才是解决问题的方法.我们很容易理解解决问题带来的价值,但也很容易忽略定义问题的力量.如果问题定义得准确,那么实现起来也不会太复杂: ...
如何在公司落地业务组件
先放一张 winter 对于前端从技术层方向的定级标准: 当然这个定级对于不同的公司也会有相应的偏差,但是可以看出掌握组件开发是通向高 T 前端的必经之路,毕竟从一亩三分地跨越到了前端工程化的领域. ...
如何落地业务建模(5) 云时代的挑战
弹性边界还是业务边界弹性边界拆分微服务,弹性优先还是业务优先弹性优先对业务建模的挑战如何保持弹性边界的独立性弹性边界间的依赖与耦合如何避免弹性耦合默认异步对业务建模的挑战弹性边界还是业 ...
Winform开发框架中工作流模块的业务表单开发
在我们开发工作流的时候,往往需要设计到具体业务表单信息的编辑,有些是采用动态编辑的,有些则是在开发过程中处理的,各有各的优点,动态编辑的则方便维护各种各样的表单,但是数据的绑定及处理则比较麻烦,而自定 ...
【转】Web API项目中使用Area对业务进行分类管理
在之前开发的很多Web API项目中,为了方便以及快速开发,往往把整个Web API的控制器放在基目录的Controllers目录中,但随着业务越来越复杂,这样Controllers目录中的文件就增加 ...
ERP系统中的工作流和业务流
首先解释两个概念: 工作流,将工作分解成几段不同的任务,然后通过一定的规则和过程来执行这些任务并对它们进行监控,达到提高工作效率,降低生产成本,提高企业竞争力等目的.它大多应用于办公自动化领域. 业务 ...
中通快递关键业务和复杂架构挑战下的 Kubernetes 集群服务暴露实践
本文是上海站 Meetup 讲师王文虎根据其分享内容整理的文章. KubeSphere 社区的小伙伴们,大家好.我是中通快递容器云平台的研发工程师王文虎,主要负责中通快递容器云平台开发.应用容器化推广 ...
软件测试中最复杂的业务_复杂软件开发项目中的有效测试
软件测试中最复杂的业务手动还是自动测试? 该软件总是由人创建,经过人测试并且在大多数情况下是由人使用的. 任何负责任的测试人员最糟糕的梦想是错过一个严重的错误. 测试人员尝试仔细检查需求并编写测试用 ...

从实际业务中来，到落地业务建模中去

从实际业务中来，到落地业务建模中去相关推荐

最新文章

热门文章