从实际业务中来，到落地业务建模中去
圖片來源：pexels.com
做了這么多年項目，不知道你有沒有發(fā)現(xiàn)一個有趣的現(xiàn)象：有時候面對同一個問題，當(dāng)我們對它的定義不同，往往最終解決方案的差異也會非常大。
拿我司之前的一個需求來說，客戶要求將一份帶有大量文字介紹的圖片報告轉(zhuǎn)換成 PDF 格式，以方便用戶下載。但由于每張圖片具體說明信息不同，所以難免會出現(xiàn)一些排版格式的錯誤。
于是，我們項目組的一位技術(shù)骨干提出了一個看似“完美”的解決方案：
利用后臺渲染技術(shù)，在服務(wù)器端的瀏覽器進程中渲染頁面，再將渲染好的頁面通過瀏覽器后臺進程轉(zhuǎn)存為 PDF 文檔，并通過云端的大規(guī)模存儲服務(wù)緩存；
另外，為了應(yīng)對突發(fā)巨量下載的可能性，還得用上當(dāng)時最先進的云計算，構(gòu)造一組后臺渲染集群，并根據(jù)下載量的大小，利用云計算的彈性動態(tài)調(diào)整集群的大小。
可以看出，他是這樣定義該問題的：PDF 中保留的信息樣式，要和用戶在瀏覽器中看到的一致。
方法是沒錯，但貌似看起來過于復(fù)雜？現(xiàn)在我們換個思路，解決這個問題前，先搞清楚客戶為什么想保留圖片的文字說明？一問才知道，圖片上的是版權(quán)信息聲明，保留是為了避免法務(wù)糾紛。
這時候，該問題的定義自然變成了：PDF 中確實要保留圖片的版權(quán)信息，但讀者只用知道其存在，并不一定要直接閱讀它。
從這個定義出發(fā)，最終的解決方案就簡單多了：當(dāng)圖片說明文字超過一定字數(shù)，直接選擇一個很小的字號，以保證信息留存在 PDF 中即可。實現(xiàn)方案，也就只是一條 if 語句的事兒。
從一個后臺渲染集群到一條 if 語句，兩者的成本和實施難度的差距不用我多說。看到?jīng)]，這就是有效定義問題的重要性。
而要想做到有效定義問題，首先得從業(yè)務(wù)實際出發(fā)，并盡力在業(yè)務(wù)中尋找簡化問題的可能性，然后在技術(shù)中尋找對應(yīng)的解決方案。這個過程，也叫做業(yè)務(wù)建模。
在上述例子中，我甚至還沒有動用任何建模手段，只靠澄清了真正訴求，就極大地簡化了解決方案。但在日常開發(fā)里，各個因素都可能極大提高問題的復(fù)雜度，所以除了清晰地理解業(yè)務(wù)訴求之外，更加需要我們通過建模的方式對這種復(fù)雜度進行簡化與精煉。
作為業(yè)務(wù)建模的踐行者和創(chuàng)新者，我發(fā)現(xiàn)平時不少人都有沒搞清問題定義而去舍近求遠做事情的困擾，所以，我和極客時間合作推出了《如何落地業(yè)務(wù)建模》專欄。在專欄中，我會系統(tǒng)講解建模所掌握的多種方法、原則，以云時代時間軸為界，帶你清晰定義業(yè)務(wù)問題，掌握在架構(gòu)下，業(yè)務(wù)建模的最佳實踐以及實現(xiàn)模式。
跟我學(xué)完這門課，相信你能快速重構(gòu)建模技能，掌握業(yè)務(wù)建模精髓和切實有效的落地方法論。無論是作為幫你高效搞定項目的方法，還是一種思維的訓(xùn)練法，業(yè)務(wù)建模都非常值得你花時間去琢磨。
秒殺+口令「jianmo666」立省 ￥80
到手六折，僅限前 50 人
我是誰？
我是徐昊（八叉），ThoughtWorks 全球技術(shù)策略顧問、中國區(qū)首席技術(shù)官（CTO），ThoughtWorks 技術(shù)雷達編撰人。談話節(jié)目「八叉說」作者。
同時我也是北京 Java 用戶組（ BJUG：Beijing Java User Group）和 Agile China 主要創(chuàng)始人之一。從 2003 年起開始實踐極限編程等敏捷方法，并多次以敏捷教練的角色幫助國內(nèi)外多個團隊實施極限編程，提高編碼迭代效率。
此外，我也曾主持 ThoughtWorks 中國區(qū)技術(shù)特種兵小巨人管培計劃，為行業(yè)輸送了多位技術(shù)帶頭人。近年提煉了大規(guī)模工程實踐方法 SEELE ，以進一步提升研發(fā)團隊的工作效能。
如何學(xué)習(xí)業(yè)務(wù)建模？
業(yè)務(wù)建模的方法有很多種，它的吊詭之處就在于，使用的難度并不在于建模本身。無論是哪種建模方法，你總能按照書里教程中的例子，照貓畫虎地做個七七八八。
但，業(yè)務(wù)建模存在兩個真正的難點：
清晰地定義業(yè)務(wù)問題，并讓所有干系人都接受你對業(yè)務(wù)問題的定義；
在特定架構(gòu)的約束下，將模型實現(xiàn)出來。
為了幫你搞定這兩點，以及更好地了解和掌握建模的最終落地，我在每一講內(nèi)容中，都按照步驟展示了很多領(lǐng)域模型，方便大家在閱讀中能夠清晰梳理整體脈絡(luò)，同時也可以保存下來，隨時查看復(fù)習(xí)。
下面這個就運用了四色建模法，以一個極客時間的專欄生產(chǎn)和售賣為例，按照關(guān)鍵數(shù)據(jù)項間的關(guān)聯(lián)，將模型連載一起，稍加潤色，補充描述對象，從而得到了如下的領(lǐng)域模型：
回歸主題，課程分為兩大板塊：
一、舊約：“前云時代”的領(lǐng)域驅(qū)動設(shè)計
這部分是過去十五年“前云時代”，我們對領(lǐng)域驅(qū)動設(shè)計應(yīng)用的總結(jié)與提煉，因而稱為“舊約”。
首先，我會為你介紹領(lǐng)域驅(qū)動設(shè)計方法。作為一種建模方法，雖不是那么出色，然而卻能夠在如何引領(lǐng)需求發(fā)掘，如何建立溝通反饋，如何與業(yè)務(wù)方共建模型等問題上，提供到一套出色的框架。
而后，我會為你介紹在多層架構(gòu)成為主流架構(gòu)選擇的時代中，領(lǐng)域驅(qū)動設(shè)計在模型實現(xiàn)上遇到了哪些挑戰(zhàn)，以及如何應(yīng)對，幫助我們理解架構(gòu)約束會對模型帶來何種影響。
最后我會介紹四種建模方法，分別是：催化劑法、角色-目標-實體法、事件風(fēng)暴與四色法，以彌補領(lǐng)域設(shè)計在建模能力上的缺陷。
二、新約：“云時代”的業(yè)務(wù)建模
如今，云時代徹底改變了我們構(gòu)造軟件的方式，微服務(wù)、中臺、軟件的 SaaS 化都是這一影響的體現(xiàn)。新的架構(gòu)約束會極大影響我們業(yè)務(wù)建模的方法，但同時也大大擴展了業(yè)務(wù)建模的內(nèi)涵。
我會來和你聊聊云到底帶來了哪些觀念上的改變，它具體的顛覆性體現(xiàn)在什么地方，以及對我們構(gòu)造業(yè)務(wù)系統(tǒng)有多少影響。
其次，我會介紹一種由我發(fā)明的業(yè)務(wù)建模方法?8X Flow 法，用于解決微服務(wù)、分布式事務(wù)為主導(dǎo)的架構(gòu)風(fēng)格中的業(yè)務(wù)建模問題。這個方法同樣可以用于構(gòu)建中臺系統(tǒng)，也是我司目前用于中臺建模的主要方法。
最后，我會介紹另一個同樣是我發(fā)明的用于 SaaS 化業(yè)務(wù)建模的方法：魔球服務(wù)建模法（Money Ball Offering Modeling）一種從運營角度出發(fā)，構(gòu)造SaaS化服務(wù)的實用方法。
還有很多具體內(nèi)容，可以看看課程目錄。
我的粉絲仍有專屬福利：
拼團 +?秒殺口令「jianmo666」
立省?￥80，僅限前 50 人！
訂閱后生成海報發(fā)給好友，
每成功邀請?1?位好友，可得?￥20?返現(xiàn)。
👇 點擊「閱讀原文」
輸入優(yōu)惠口令?「jianmo666」
立省 ￥80?入手，僅限前 50 人
總結(jié)
以上是生活随笔為你收集整理的从实际业务中来，到落地业务建模中去的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 平均工资达 1.6 万元！2020 年一
- 下一篇： More than one file w