圖片來源：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?返現。

👇 點擊「閱讀原文」

輸入優惠口令?「jianmo666」

立省 ￥80?入手，僅限前 50 人

總結

以上是生活随笔為你收集整理的从实际业务中来，到落地业务建模中去的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。