C03：架構，面向人的設計，面向業務的建模

原創

uoge

2020-06-27 13:09

破局能力

前面兩篇帖子說了架構設計和業務的關係，以及架構設計的重要性，那這篇我們來探討一下架構設計應該如何做。

實際場景溝通中經常會遇到此類：“領導說讓這麼做”，“客戶端讓我加個字段”，“前端要加一個結構”這類都是沒有思考自己要解決什麼問題，不去掌控問題，最後肯定會被問題所累。

首先提一點就是破局能力，這算是內功和心法，假如事情發展朝着錯誤的方向,事情越來越被動，不要讓相關方亂推你，隨着事情發展自己也會越來越被動，要有破局能力，不要讓各方推着你走到最後搞的無路可走只能失敗告終，要引導，客戶業務方，老闆，給大家能看懂的語言，給大家信心，讓大家支持你，要有掌控力。

產品設計者和架構設計者，總有一些通用的特性，往前比他人看的遠，往後比他人看的詳細，總能洞悉一些東西，找到和抓住重點和本質的一些東西，而這些東西最終體現就是對產品的規劃，對技術的架構設計

架構設計的描述

架構設計中的幾大核心元素，在這裏我們設計其實是給相關方做的

做事情的時候一定要想着給誰在做這件事情，而不是爲了工作而工作，不同的架構視圖關注者時不一樣的，那做到什麼程度才
算到位呢？就是關注者能理解的程度，架構視圖和設計是給相關方去做的，一定要確認他們關心什麼，他們能否能看懂，好理解，這些個心理一定要有個譜，不同的環境，不同的人，有的心照不宣，有的一臉懵逼，需要區分不同去對待

架構設計是語言用來溝通

架構設計這塊目前接觸到的有4+1視圖設計和UML，其中UML更爲廣泛和爲大家所理解。
UML，爲啥最通用的架構語言，因爲語言是用來溝通的，用來和關注方溝通，開發溝通，後續的讀者溝通。

設計語言能幫我們解決什麼問題？

“誒，咋做成這樣？和正確的預期不一致啊！這樣做有問題，這不能解決用戶的問題，這個功能不能上線！！！”

語言的特性就是溝通，和開發產品需求測試溝通，確保產品的相關方都在用統一的語言來描述一個事物，避免理解不一致造成中間的反覆溝通，避免因需求期望的，開發實現的，測試要驗證的預期不一致而導致迭代失敗，解決上述問題的關鍵在於，產品理解的解決和開發要實現的內容要一致，這個最終體現是場景用例的分析和DOD標準的設立

“一句話需，描述簡單不代表實現就簡單，這個報表很簡單估計一下午就做完了，真正開始做的時候發現數據源不支持，微服務之間調用困難，服務之前數據關聯不方便，結果開發實現了3天，最終因性能問題和太過複雜，任務交付失敗”
通過概要的設計和詳細的設計，你可以瞭解到各個組件之間如何交互，數據庫如何設計，數據如何流動，最終業務如何展示，只有這些都明細之後這個任務的複雜度纔算有了一個清晰的認識，不然就會出現上面的問題看似簡單，其實不然
我們把設計和思考沉澱在文檔和圖表上，這樣我們大腦的內存就騰空了一部分，可以繼續思考“思考之外的”思考，在深度和廣度兩個方面進一步提升，幫助自己做出更優秀的設計
人的注意力是有限的，宏觀的脈絡和微觀的細節同一時間只能關注一個，假如沒有一個大綱和藍圖來指導和糾正，最後一定會跑偏，結果和預期不相符合