架構(gòu)的方法：運用合適的工具表達設(shè)計

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

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

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