導讀
軟體裡的要素不是憑空出現的，都是源于實際的業務。本文從軟體設計本源到模組化案例系統的介紹了作者對于模組化的思維和思考。
一、諸内必形于諸外
軟體開發工程師與醫生、建築師所做叢事的工作在本質上沒有差别，都在解決現實遇到的問題，是以大家做事的方法也具有相通性。《黃帝内經》中講到“有諸形于内，必形于外”，意思是人的身體内有了毛病,一定會在身體表面顯現出來。比如我們常知道的感冒，有風熱感冒和風寒感冒之分，如果咳嗽吐痰是白色的是風寒感冒，咳嗽吐痰是黃色的是風熱感冒。
是以，你會看到我們遇到的問題有表象和本質之分，表象是我們直覺能看到的，本質往往是不明顯的，是需要深入分析和思考才能得出。國醫大師熊繼柏把治病總結成兩個關鍵點：一是病變部位；另一個是病邪性質。病變部位是具體在人身體哪個部位出現了問題，病邪性質是風、寒、暑、濕、燥、火中的哪一種或幾種。是以，治病關鍵要知道身體裡的哪個部位因為什麼産出了疾病，如咳嗽是由于肺部受寒引起的，故治療的方法是溫陽散寒，宣肺止咳。而病變部位和病邪性質會表現在人身體的外表上，如鼻子顯現出來的問題與脾胃關聯性比較大，眼睛顯現出來的問題與腎關聯性比較大。
醫生治療的方法有非常多，如八綱辯證、三焦辯證、衛氣營血辯證等，國醫大師通過病變部位和病邪性質高度抽象出了治病的本原，那麼軟體設計的本原又是什麼呢？
二、軟體設計本原
2.1 軟體是現實世界的“相”
在财務領域裡做了2年時間裡，讓我深刻認識到一個體會：軟體裡的要素不是憑空出現的，都是源于實際的業務。比如财務裡的收入，一定是某個具體的業務在某個場景下産生的，絕對不會憑空地做一筆财務收入出來，是以軟體世界與現實世界是有關聯的，軟體裡的要素一定是來源于現實業務。
軟體設計的本原是将現實的“相”映射到軟體中，将現實的“相”在軟體世界中勾畫出來（模組化的過程）。現實的“相”可以通過在軟體中表達，也可以通過人自己去表達，就像财務領域，沒有财務軟體财務同學照樣可以做賬，比如财務同學用Excel做賬。不管是财務軟體，還是财務同學自己，本身都是要去了解現實的“相”，隻不過一個是在軟體中，另一個是在财務同學的大腦中。
軟體就像照鏡子一樣，将現實映射到鏡子中，是以現實發生了什麼，軟體中就發生了什麼。比如我們買火車票，在12306網站出現之前，我們要到火車票售票視窗買，支付錢後售票員給我們一張火車票，在12306網站出現之後，我們在網站上支付錢後，我們就有一張電子火車票，兩個是不是很相似呢，我們在現實中的行為映射到軟體中的操作。
那麼現實的“相”又是什麼呢？我借用财務領域的一個概念來表達，“相”即是業務事實，業務事實是通過業務事件可觀測的，顯性的業務事件好比“諸外”，隐性的業務事實好比“諸内”，“諸外”的業務事實和“諸内”的業務事實構成了業務模型。不管你有沒有感覺到，業務事實是客觀發生的，就像你不是研究電磁波領域，但電磁波無時無刻在發生，隻不過你沒有關注而已。有的業務事實是可直接觀測到，比如電商下單購買商品，有的業務事實是無法直接觀測到的，比如WIFI，WIFI是看不見、摸不着，但它是客觀存在的，是以“相”是有層次結構的。
2.2 “相”的層次結構
“相”是有層次結構的，我将它分為兩層：現象層和規律層，規律層決定現象層的表現，這個與諸内必形于諸外是同一個道理。比如交易系統，本質是平台協同賣家履約交易合約，是以在現象層我們會看到有買家下單、賣家發貨、物流配送、買家收貨、賣家收到錢的業務事實，而在底層驅動交易進行的是交易合約，它定義了平台、買賣家的行為，驅動着交易流程推進，買家支付後，賣家就要發貨，買家收到貨後，平台就要将錢支付給到賣家。
感覺現象層最簡單的方法就是照着流程走一遍，就會知道整個流程中發生了什麼事，而洞察到規律層就沒這麼簡單了，要找到決定現象層的本質規律需要在這個領域有非常深的領域經驗，領域是有專業壁壘的，正所謂外行看熱鬧，内行看門道。現象層是可觀測的，更多的是在使用歸納法，不斷在收斂、歸納業務事實知識；而規律層更多的需要使用演繹法，把業務事實的本質定義出來，往外發散，同時它是可被推導出來的（因為它是客觀存在的）。
對應到軟體設計中，如果我們隻看到現象層的業務事實，那麼設計出來的系統是面向業務場景和業務流程的功能設計，而業務場景和業務流程是發散的，具有多樣性，那麼系統的通用性、複用性會比較差，表現出來的現象是業務需求的研發效率提升不上去，平台能力不斷在疊代更新，需求側等平台側排期。
我自己是有過做過業務系統和平台系統的經曆，在這一點上有比較深的感觸，在做平台系統時習慣于做業務流程抽象，而忽視了領域本質業務事實的抽象，像業務場景、業務流程不是平台系統應該關注的事情，職責也應該交由業務系統的開發同學，平台專注于本質業務事實的處理，就像前面提到交易系統一樣，需要專注在交易合約上。一個不太嚴謹的區分現象層和規律層的業務事實方法，如果兩個處理的業務事實是同一個，大機率是現象層中的業務事實，就像作業系統中的核心開發和應用層開發，兩個關注的東西和層次是不一樣的，平台中如果處理的對象是業務系統中的對象，隻能說抽象層次不夠，還沒有抽象出領域的本質業務事實。面向業務流程和業務模式抽象建設平台的方法被證明是失敗的平台設計方法。
2.3 軟體設計本原的要素
前面提到軟體設計的本原是将現實的“相”映射到軟體中，将現實的“相”在軟體世界中勾畫出來，那麼落地到軟體設計中應該關注哪些要素呢，或者說如何具象軟體設計本原關注的事項，就像醫生治病看病變部位、病邪性質那麼簡潔。
業務事實是伴随着業務事件出現的，即一個業務事件出現了，對應着有一個或多個業務事實出現，比如财務收入的确認時點是使用者簽收的那一刻，那麼使用者簽收就是一個業務事件，财務收入又會細分成多種收入，每一種收入對應一個業務事實。業務事實之間并不是孤立存在的，彼此間有關聯關系，是以，軟體設計本原要素我總結出來就三個：看業務事件；找業務事實；建事實關聯邏輯。
看業務事件是觀察業務發生了哪些事件，所有軟體具備的能力是要以某種方式對外表現出來的，這種方式就是業務事件。業務事件是冰山上層可直接觀測的，隻要投入精力就可獲知到。我比較欣賞的一句話是“沒有調查就沒有發言權”，都沒有了解事情，怎麼能做出判斷呢，看業務事件是在收集資訊的過程中，為找業務事實和建事實關聯邏輯打基礎，全面了解業務是設計的前提。
業務事實是要找的，它并不是全部具象地展示在我們面前，比如使用者下單，我們可以得到一個訂單的業務事實，它包含了買家家、金額、商品、下單時間等資訊，訂單業務事實底層還有訂單合約這個業務事實，越是接近業務本質的抽象，系統設計出來才更通用和靈活，反之是基于現象和流程歸納出來的是不穩定的系統設計，就像交易有很多種模式，如擔保交易、及時交易等，好的抽象應該是不關注這些的。以作業系統為例，它會關注具體的應用是視訊應用，還是通訊應用，亦或是文檔應用嗎，對于作業系統來講，就是一個個的程序，是以在前面提到業務開發和平台開發關注的層次是不一樣的，兩個處理的業務事實也不一樣。建議的做法是先把業務場景和業務流程對應的業務事實找出來，做一個基礎的模型設計，然後再将場景類型發散，考慮多種可能性，再看看不變的業務事實是什麼，或者到底是什麼業務事實在起關鍵作用，領域本質在解決什麼問題，對領域本質了解得越深刻，會越接近業務的本質。同時反問自己這是本質的業務模型嗎，逼迫自己往深層次思考，探索本質的業務事實和業務模型。
在軟體世界中勾畫出現實的“相”，即是建一個軟體模型表達現實的“相”，建事實關聯邏輯即是建軟體模型的過程，軟體模型是一個最終的産物，過程中是要建立事實之間的關聯邏輯，比如使用者下單後有支付單，訂單和支付單之間就有關聯關系，用模型去表達現實業務事實運轉邏輯，它能極大的簡化對複雜問題的認知成本，後續的系統開發中的對象也是基于這些業務事實對象進行開發。
三、模組化案例
或許你之前聽說過不同的模組化方法，如用例模組化、四色模組化、事件風暴模組化，其實本質是相通的，都是在軟體中勾畫出現實的“相”，隻是找現實“相”的方法不一樣而已，表達方式不一樣而已。而且模組化并不是隻是技術同學的工作，業務、産品、測試同學都可以進行模組化，模組化不僅能簡化複雜問題的認知，而且還能減少溝通成本，我曾遇到一個概念3個月内不同的人反複在問是什麼含義，每次都要解釋，溝通成本非常高。
在模組化的過程中，你會體會到抽象的樂趣，越是深刻、靈活的模型，往往就越抽象，模組化考驗的是不是能把客觀業務事實概念化地呈現出來，是以先觀察業務事實有什麼，再用概念把它表達出來，這裡有一個觀點：關系即結構，結構即模型，我們本質是要建一個能展現現實業務運轉的模型，這個模型包含動靜兩方面，靜的方面即是模型結構，動的方面是互相之間的依賴關系。下面列舉一些我做過或看到的模組化案例，複雜度也是層層遞進的。
3.1 現實映射抽象
每次講到模組化時，我都會把它當作一個案例講，因為它不僅簡單，而且它展現了設計思維的轉變（有别于面向過程設計的思維）。第一個案例相對簡單些，是店鋪的導航欄，我們可以直覺地看到一個店鋪有一個導航欄，導航欄裡有多個導航Tab，不同的店鋪導航Tab個數不一樣，比較有的店鋪參加了雙11大促，就會有一個雙11Tab展現出來。
這個模型相對比較好了解，包含了兩個概念：導航欄和導航Tab，這個與現實業務事實是一一映射的，是以我們可以畫出它的模型。
雖然這個例子比較簡單，但它是展現了最基礎的模組化的思想：現實有什麼，軟體中就有什麼，回到軟體設計本原上，軟體設計最核心的工作就是還原業務事實，把業務事實原本的模樣抽象出來。是以，你會看到，我壓根兒沒有考慮過程，面向過程是人為的把自己當作了“導演”，“導演”了整個流程，隻是這個流程是你自以為是的流程，流程的工作應該放在業務層中實作，領域層是不會關注的。
3.2 抽象層次升維
第二個例子是Martin Fowler在《分析模式》中的第一個例子，例子本身也不複雜，是一個通訊錄的模組化例子，模型如下：
以上這個模型是對現實業務事實一一映射抽象出來的模型，但它不足以展現通訊錄的模型，現在隻有個人和公司，還有可能是政府、法人組織等，是以這個模型并沒有從本質上刻畫出通訊錄的本質。Martin Fowler對其優化後的模型如下：
這裡做了兩個概念抽象，首先是有一個參與方的概念，另外有一個組織的概念，将之前個人和公司往上做了一層抽象，然後在泛化出具體子類時，并沒有使用之前公司的概念，而是使用了組織這個概念。
盡管這個例子本身并不複雜，但它給我們揭示了模型要展現普通性，并不是你所看到的業務事實，它還可能包含其它的業務事實并沒有被觀測到，沒有觀測到并不表示它們不存在。是以，在模組化時要想一想，還有沒有其它的業務場景，業務的多樣性會不會對業務模型帶來沖擊，是以，全面的調查是設計的基礎，要不然是解決了一部分問題（沒有調查就沒有發言權，實踐出真知）。
3.3 找隐性概念
第三個例子也是Martin Fowler在《分析模式》中的例子，它是第三章測量模式的例子，稍微有些複雜。先解釋下數量這個對象，它是包含數值和機關兩個屬性，比如10千克，其中10就是數值，千克就是機關。這個案例的背景是在醫院中為每個患者收集數十種測量值（身高、體重、血糖水準等），此時可以将數量作為人的屬性（相當于要取最大的測量類型），但是如果考慮到整個醫學領域，那麼一個人可能會有數以千計的可能測量值。為每個測量定義一個屬性意味着對一個人可能有成千上萬種操作，這将形式一個不切實際的複雜接口（幾十種測量還能勉強接受）。
如何解決這個問題呢，Martin Fowler抽象出測量這個概念，人是包含了測量這一個集合屬性，不像之前要包含成千上萬種測量屬性，将每種可測量的事物（身高、體重、血糖水準等）抽象成現象類型，現象類型相對是可枚舉的，測量這個對象包含現象類型和數量兩個屬性，如下圖所示。
Martin Fowler提出了兩條模組化原則：一條是操作層包含那些每天都在發生變化的概念，這些概念知識的配置由知識層進行限制，其變化頻率要低得多；另一條是如果一個類型有非常多類似的關聯，那麼将這些關聯對象抽象成一個新類型，再建立一個知識層類型來區分它們。
往往隐性概念比較難挖掘，當你沒注意到時，在實際開發過程會存在大量重複的操作，或者非常複雜的處理邏輯，就像上面提到的，即使寫10幾個數量屬性，也夠麻煩的；當你注意到時，你又會覺得很自然，比如現在你看測量這個對象就非常順眼。另外有一點是變化可枚舉的事物可抽象成類型概念，比如有支付寶支付、微信支付，可抽象成支付方式或支付類型。
四、小結
- 有諸形于内，必形于外。
- 軟體設計的本原是将現實的“相”映射到軟體中，将現實的“相”在軟體世界中勾畫出來。
- “相”即是業務事實，業務事實是通過業務事件可觀測的。
- 面向業務流程和業務模式抽象建設平台的方法被證明是失敗的平台設計方法。
- 沒有調查就沒有發言權。
- 軟體設計本原要素我總結出來就三個：看業務事件；找業務事實；建事實關聯邏輯。
- 業務事實是要找的，它并不是全部具象地展示在我們面前。
- 模組化考驗的是不是能把客觀業務事實概念化地呈現出來。
- 關系即結構，結構即模型。
- 現實有什麼，軟體中就有什麼。
- 軟體設計最核心的工作就是還原業務事實，把業務事實原本的模樣抽象出來。
作者:不拔
來源-微信公衆号:阿裡雲開發者
出處:https://mp.weixin.qq.com/s/_pD-TTj-Lj68S4PsWVNlLA