首先聲明，可能本篇文章的含金量配不上這個標題，因為說起架構，可能大家都比較關注高大上的架構，比如分布式的，高并發的，低耦合的，易擴展的等等，本篇可能使你失望了，因為這些全沒有，這篇博客的中心思想是——適合的架構，就是好的架構。

古時候談婚論嫁，講究“門當戶對”，新時代是不接受這種“封建思想”的，如果我們把“門當戶對”的意思，理解的更寬泛點，可能情況就不一樣了，門當戶對，不僅僅從經濟，名譽上來理解，擴展到三觀（世界觀，人生觀，價值觀）上，是不是兩個人，或兩家人三觀一致的話，是不是覺得就有道理了，有點哲學的意思了。言歸正傳，說架構。

相信有很多人遇到這樣的用戶，給我做個淘寶吧，或給我做個美團外賣吧，更多的是我要做個XX項目，和某某(大廠應用的名字)一樣，這個時候，一般情況下大家都是心里在笑，笑什么呢？笑的人都心里清楚的很。對非行業里的人來說，難免。對于行業里的人來說，首先要了解做什么項目，為誰做項目，用戶量是多少，訪問量是多少，再就是項目預算是多少，工期是多長時間等等問題。要充分了解項目或系統的信息，其實這些信息都是對架構有影響的。

接下來分成兩方面來看

• 外部——客戶

客戶要解決什么問題

客戶系統的行業很關鍵，系統是偏計量統計，還是工作流程，還是費用相關，每個行業對軟件的要求都不盡相同，難做的與錢打交道的軟件，和容錯率低的軟件，對對開發者有更高，更嚴格的要求。

使用系統有多少用戶

同時使用的用戶數，這個是引導架構技術設計的主要因素。

開發工期有多少時間

時間有時會改變我們的架構的，有可能時間短，只能選最熟悉的架構，而不是最合適的架構，

客戶有多少預算開發

這個更敏感了，這決定投入的人，時間，精力，最簡單的，預算如果不充足，可能連架構師都不一樣了，選一些能力，經驗相對少的人來操刀。

• 內部——開發

技術人員

可調度的技術人員有多少，他們的專長技術是否滿足你的架構，能否保證完整的在這項目的生命周期內。

系統需求交付概要情況

需求是否明確；交付是一次交付，還是邊開發邊交付

系統適合什么技術實現

宏觀上要大體上有這個項目實現是什么架構：C/S，B/S，單體，微服務，前臺應用，后臺服務等

項目越大，影響架構的因素越多，這里只隨想了幾個方面，不足以覆蓋全部場景，更適合的小項目，小團隊參考，畢竟小項目的數量要遠遠大于大項目，同時小項目的質量，架構合適性要劣于大項目(可能關鍵在預算上吧)。

對于一個模塊，一個項目，一個系統，要做到適合的架構，不僅要考慮技術，交付工期，還要客戶資源，預期等方面，這樣才能做出一個雙方都共贏的產品，皆大歡喜。

總結

以上是生活随笔為你收集整理的.NET架构小技巧（6）——什么是好的架构的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。