架構的方法：運用合適的工具表達設計

1、架構設計的關鍵在于思維。
不是因為PPT里的大部分內容講的是UML，就花大把時間去學習如何畫UML圖，去嘗試各種UML工具，去理清各種UML圖的細節，而是要理解UML圖背后所代表的看待架構的思維。
比如，用例圖，它從用戶的角度來描述系統的功能以及各個功能的執行者，強調的是使用者和功能。它從使用者的角度來看待一個系統，可以幫助我們從宏觀上理清系統的所有功能點以及各個功能點之間可能存在的聯系。
再如，時序圖，把用例圖表達的功能點，轉化為更進一步，更加精細的表達，它幾乎是自描述的，并且顯示了流程中不同對象之間的調用關系，同時還可以很詳細地顯示對不同對象的不同調用。它從開發者的角度來看待系統，讓系統的關鍵流程變得容易理解，特別有利于初級開發者或對業務不熟悉的同學。
最后，比如部署圖，更強調系統運行時需要的物理節點以及各個節點的配置，其強調物理設備之間的關聯關系。它更多的是從運維的角度來看待系統的，可以幫助運維理清該如何部署以及平衡物理資源的分布。
綜上，UML背后體現的思維是：在軟件的不同階段，站在不同的角度，通過不同類型的圖表來指導架構的設計。我覺得，UML更多的意義在于表達，即通過一些標準化的約束和圖表來描述我們的設計。所以，很遺憾，UML并不能教你如何設計，它只是一個工具而已。
很贊同的一個關于架構設計思維的觀點是：架構設計的關鍵思維是判斷和取舍，程序設計的關鍵思維是邏輯和實現。
所謂判斷，即通過對需求的理解，識別系統復雜性所在的地方，并針對這些復雜點進行架構設計。所謂取舍，即有的放矢，而不是面面俱到。
比如，對于一個確定的功能點，不同的性能要求，設計思路是不一樣的。如果性能要求不高的話，不需要使用緩存，也無需引入各種中間件；而如果性能要求很高的話，可能就需要使用消息隊列和緩存等組件來提升性能。
但也要避免陷入貪大求全的境地，不根據實際情況，什么都想滿足，既要高可用又要高性能，這就是沒有很好的進行取舍和平衡。
判斷和取舍才是架構師在架構設計時，應該著重關注的點，如果僅僅是通過UML把各種圖表畫出來，更多的還是停留在工程師思維，僅關注了程序的邏輯和實現，這并不有利于我們做出好的架構設計。
而如何進行判斷和取舍，則要看我們在技術深度和廣度上的積累，這不是參加一個訓練營就能解決的問題，只能說道阻且長，我們還需努力。

2、關于人
架構設計的第二個要點是人，即相關方。
在架構設計中，相關方指的可能是系統的各個角色用戶，即什么樣的人會如何使用系統；也可能是實施整個架構的開發工程師、測試工程師以及運維工程師；甚至可能是要時刻關注系統研發的老板等等。
不同的相關方，對架構設計的成果的期待是不一樣的，這個需要根據團隊的實際情況來考慮和取舍，這也是指導架構師設計的重要標準。
比如，對于老板，其可能更關注實現整個架構需要的人力、物力、時間成本；而對于項目經理可能會更關注架構的邊界以及和其他團隊的協作配合上；對于開發工程師，可能更關注架構涉及到的各種技術以及實現方式。作為架構師，需要考慮不同相關方的期待，以此來指導設計。
特別想說的是，整個架構設計要特別關注的角色，其實是開發工程師。在架構設計中要根據開發工程師的技術水平給予適當的發揮空間。如果團隊都是新手工程師，可能需要像課程中一樣，細致到關鍵流程的時序圖、類圖，工程師只需要實現即可，這樣可以最大程度的保證軟件質量。而如果團隊中有很資深的工程師，在關鍵業務流程以及組件使用上，最好與其充分討論，得出一致結論。這時候，架構文檔只要起到記錄的作用即可，也就無需太細致，具體的實現留給工程師自己發揮吧。

3、關于工具
架構設計的最后一個要點是工具。在架構設計中，工具是一種語言。
既然是語言，其最重要的作用就是交流。只要相關方可以理解，選擇什么樣的工具就變得不那么重要。
UML作為標準建模語言，全世界通用，但如果你的團隊沒人學習過，那大可不必一定要使用。比如，用例圖你完全可以畫框圖來代替；流程圖也可以代替時序圖的部分功能。
因此，工具的選擇是與人緊緊相關，無關乎好壞優劣，選擇合適團隊的就好。
這也是為什么把工具的重要性放到最后一個的原因。就我個人而言，如果不是因為作業需要，短時間內不會去看或者學習任何UML相關內容，畢竟周圍沒人通過UML溝通和交流。也正如老師所講，如有需要，花半個小時學習即可。