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