不寫單元測試的碼農不是好的廚師，哪怕您只想擼一生增刪改查，可能公司也不允許。現實公司，多數同學還是業務開發，業務開發往上一個臺階，很容易想到業務架構師，今天我們來聊聊業務架構。
公司/業務
實際上，所有公司都有一個最本質，最底層的需求：活下去。
活下去，就需要盈利。那麼，一家公司是怎麼盈利的？創造什麼價值？提供什麼產品？目標客戶？渠道？上下游？整個業務鏈路是什麼？
在這個基礎上，把我們負責（或者即將開發）的系統套進這個大的業務鏈條中去思考。我們負責的系統，佔據什麼樣的位置，和其他系統怎麼交互，如何影響和干預最終的結果。 這纔是真正的“業務”。
以常見的電商公司的訂單系統爲例，訂單系統，上游必不可少有購物車，有支付,營銷，商品，價格。訂單是是履約的基礎，下游有物流，財務，如果是自營，和倉儲管理系統之間也會有交互。
如果你沒思考過這個問題，從現在開始也不晚，先從宇宙公司的中臺戰略開始。
恰如其分地設計
不存在的。這是一場產品經理+項目經理和架構+開發的戰爭，好的架構師要活下來，必須通曉業務，不求熟悉到具體邏輯細節，但是上一節的內容我們得做好，要充分理解系統的定位，上下游，輸入輸出，交互，識別核心/非核心業務，方有勝算。
產品經理比我們更清楚業務的具體問題，痛點，但是他們通常只會拋出問題的解決方案，而非問題的原貌。當解決方案不合理時，可能引導我們錯誤/過度設計。我們得有依據懟產品，依據就是我們也懂業務，更懂實現的細節。
另外一個問題是，過度設計幾乎不可避免。凡是有架構經驗的開發，遇到一個新的功能，第一件事就是腦補以後可能出現的其他場景，全部預留設計。預留設計可能帶來的問題是，增加系統複雜性，開發量增加，延遲上線或者加班。而針對這個問題，比較合理的解決方案，也只有一個，就是做好上一節的內容，清晰理解業務（核心/非核心），對其中可能變化的部分預留設計，對相對穩定的部分粗暴處理，平衡進度和設計的衝突。
平衡/決策
架構 = 可讀性 > 性能
架構的合理，其實和代碼的合理很類似，高內聚，低耦合，可擴展。
系統的可讀性，這個概念比較少聽到，先當成我發明的。什麼意思？就是系統的邊界，可擴展性，複雜度要控制在一個合理的範圍。
其中一個原因是，過於複雜的系統通常沒有好下場，後面重構的人看到只會吐槽而不想動，也會提高客戶的學習成本，運維的複雜度。如果系統內太過複雜，考慮抽象一層，一個系統不夠就兩個（沒有什麼問題是加一層解決不了的）
好的代碼，不用註釋也能看懂，結構清晰，封裝合理，最複雜的邏輯僅僅是存在某些業務方法的實現裏面，方法描述和方法實現分離，我們關注的是描述，關係的合理。好的系統設計也該如此。
性能是一個誤區，有些老司機會過於追求性能，放棄架構的合理和可擴展性。通常來說，具備可擴展性的系統，通過水平擴展可以處理性能問題，當然在特定場景，比如說11.11，爲了極限的性能放棄部分合理設計，也有合理性。實際上大多數性能問題還扯不上架構，關鍵把SQL稍微優化做好就完成了大部分工作，具體可出門向左轉，看看MySQL語句的優化。
架構，其實就是一個決策，平衡的過程。比方說涉及資金支付的系統，性能的重要性遠遠不如安全，健壯。如果是日誌或者監控系統，那適量丟消息並不是大問題，總體性能更重要。
技術積累
這個必不可少，視野內的，通過一小段時間學習能掌握的技術，是技術選型的最大範圍。視野決定上限。
不只是寫代碼纔是技術，瞭解系統的全面認知，對業務的上下游的理解和掌握也是技術活。視野來自於你的要求，對自己的要求決定你的上限。
有圖有真相
最後，請把你的積累沉澱在wiki，xmind，visio上，記錄下來，哪怕只是一個小功能的輸入輸出的數據處理流程，把裏面的組件替換成模塊，和系統交互圖差別已經不大了。
關於作者
熱衷於教產品做人的開發者，加班夜不歸宿的重度脂肪肝患者.