上工第一天，我們先來聊聊軟體架構師的日常。

答案我相信不會讓人很意外，那就是無止盡的設計/實作審閱(Design Review)。

但參與過無數設計審閱，我發現大部分的開發者其實並不了解架構師想要看到什麼，也不知道要怎麼讓架構師能在過程中充分發揮作用。因此，我來介紹「如何讓你像個專家般做設計」。

身為架構師，我想看到的重點有三項：

1. C4模型
2. 使用者故事與使用案例
3. 設計決策

不是REST API，更不是資料庫綱要(schema)。

接下來我們一個一個解釋。

C4模型

這是整個設計審閱最重要的項目，但為什麼這麼重要？我們有必要了解C4模型的含義。

C4模型是由四個C的首字母組成：Context、Container、Component和Code。

1. Context：中文翻譯成上下文。這是整個系統的總覽，用以描述使用者和系統間如何互動。因為是從使用者的視角出發，所以系統的細節並不會在此描繪。
2. Container：這並不是指Docker相關的容器化技術。C4模型中的Container指的是可以個別部署的獨立組件，包含API、資料庫或訊息佇列等。
3. Component：在C4模型的Component則是Container的進一步展開，用來描述模組與模組間的關係，或者在領域驅動設計下，亦用來描述領域和領域間的關係。
4. Code：這是最後一個C，也是最容易理解的。就是程式碼中物件和物件的關係。

從上述可知，C4模型的目的是為了解釋系統中的各種關聯與互動。從最大的單元：使用者操作，到最小的單元：物件，這些互動關係可以幫助架構師對整個系統有一個全面的了解，並且有機會查看各種互動是否合適。

舉例來說，一個小型的應用程式以Container的角度來描述會類似這樣。

一些開發者可能會認為這麼單純的圖真的有用嗎？事實上，這樣單純的圖就有足夠的資訊能讓架構師發現潛在問題。

• 擴充性：當使用者的數量增加，API有辦法承受嗎？如果API可以，那資料庫呢？
• 可靠性：當API故障，會不會導致單點失效(SPOF)？
• 效率：當儲存的資料增加，會不會延長資料庫回應的延遲？使用者會不會感受到卡頓？

這些非功能性需求(non-functional requirements)都可以藉由分析關係圖來發掘，此外，上述列得僅僅是部分常見的非功能性需求，在wiki內有完整的清單。

那麼，再用Component來舉個例子。一個簡單的社群網站可能會類似如下。

這也是一個非常單純的圖，這真的有辦法看出問題嗎？答案是肯定的。

當我們在評估耦合程度時，我們常用不穩定度作為指標。

Ce指的是傳入性耦合(efferent coupling)，而Ca則是傳出性耦合(afferent coupling)。不穩定度越接近0，代表整個模組越穩定，反之則是越容易被修改影響。

上面例子中，推薦模組的不穩定度是0.8，這表示推薦模組不太穩定。只要任何依賴模組被改變了，無論是界面或行為，都會直接或間接的影響推薦功能。

架構師正是透過這些關係圖來分析整個系統。根據不同領域和不同架構，會有完全不同的解耦作法。若是沒有一個完整的架構，架構師就只能提供一些無關痛癢的建議。

使用者故事和使用案例

使用者故事和使用案例其實在功能需求提出時就應該會被清楚討論了，但如何將商業端的術語或邏輯轉換成工程端能理解的案例同樣也是設計審閱的重點。

此外，使用者故事和使用案例其實正對應了C4模型中的Context。在工程端要能夠定義好的故事和案例，才有辦法正確的畫出Context。

設計決策

設計決策是整個設計審閱的核心。

整個設計審閱的目的其實是檢驗每個決策是否正確。前面提到的C4模型和使用者故事與案例都是為了提供足夠的背景資訊，以便了解每個決策的背後意義和風險。

但，到底什麼是設計決策？

感覺是個簡單的單字，但有點難感受到實際的樣子。所以我提供一個簡單的公式：

為什麼A(而不是B)？

舉例來說

• 為什麼用MySQL而不是MongoDB？
• 為什麼要快取？(而不是直接存取資料庫)
• 為什麼用同步的REST API而不是非同步的CQRS？

上面幾個問題都有點廣袤，讓我們繼續縮小範圍。

• 為什麼讓推薦系統用同步呼叫從貼文系統取資料？
• 為什麼將這個函式拆成兩個子函式？
• 為什麼這行程式碼寫成這樣？

有注意到嗎？這些都是設計決策，大至系統面，小至每行程式碼。不過，在一場設計審閱中，應該是不需要探討每行程式碼。那到底什麼樣的決策應該要在設計審閱討論呢？

我認為，前三個C是最值得討論的。藉由列出在圖形中的每個區塊和線條，並描述理由，這將有助於架構師在眾多功能性和非功能性需求中了解潛在問題和隱藏威脅。

至於最後一個C，我想就留給開發者們在程式碼審閱討論即可。

結論

今天我們解釋了三個在設計審閱時最重要的項目。

C4模型提供架構師一個途徑了解整個系統，而使用者故事和使用案例幫助架構師認知要解決的商務需求，最後開發者提供設計決策，如此一來，架構師能夠理解每個決策背後的取捨。

透過這樣的方式，每個人都會在同樣的起跑線上。架構師可以給合理的建議並指出系統背後的風險，而開發者也能知道系統有哪些該被解決的問題並該如何演化。

重要的是，請記得要提供架構師足夠的訊息，才有辦法得到正確的建議，不然只會聽到空話。