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

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

 

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

 

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

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

早鸟 + 秒杀口令「jianmo666」
立省 ¥40，到手仅 ¥89！

 

我是谁？

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

 

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

 

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

 

如何学习业务建模？

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

 

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

1. 清晰地定义业务问题，并让所有干系人都接受你对业务问题的定义；

2. 在特定架构的约束下，将模型实现出来。

 

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

 

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

 

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

 

我的粉丝仍有专属福利：

早鸟 + 秒杀口令「jianmo666」
立省 ¥40，到手仅 ¥89！

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

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

 

 👇 点击「阅读原文」

输入优惠口令 「jianmo666」

立省 ¥40 入手，仅限 前 50 人