聊聊领域分析与业务建模

聊聊领域分析与业务建模_第1张图片

图片来源:pexels.com

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

聊聊领域分析与业务建模_第2张图片

新人首单 ¥59.9,原价 ¥129

早鸟+口令「jianmo666」立省 ¥40

 

我是谁?

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

 

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

 

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

 

如何学习业务建模?

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

 

但,业务建模存在两个真正的难点:

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

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

 

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

 

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

 

聊聊领域分析与业务建模_第3张图片

 

回归主题,课程分为两大板块:

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

聊聊领域分析与业务建模_第4张图片

 

我的粉丝仍有专属福利:

新人首单 ¥59.9,原价 ¥129

早鸟+口令「jianmo666」立省 ¥40

 

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

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

 

 

???? 点击「阅读原文」

输入优惠口令 「jianmo666」

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

你可能感兴趣的:(java,python,机器学习,大数据,编程语言)