根據要解決的問題，對目標系統的邊界進行界定。
並對目標系統按某個原則的進行切分。切分的原則，要便於不同的角色，對切分出來的部分，並行或序列開展工作，一般並行才能減少時間。 並對這些切分出來的部分，設立溝通機制。
根據3，使得這些部分之間能夠進行有機的聯絡，合併組裝成為乙個整體，完成目標系統的所有工作。
要做好架構所首先必須具備的能力，就是能夠正確的認識概念，能夠發現概念背後所代表的問題，進而才能夠認識目標領域所需要解決的問題，這樣才能夠為做好架構打好基礎。
做好架構首先需要做的就是識別出需要解決的問題。一般來說，如果把真正的問題找到，那麼問題就已經解決了80%了。這個能力基本上就決定了架構師的水平。任何找上架構師的問題，絕對都不是真正的問題。需要從問題暴露的點，一點點去溯源查詢，一定會找出來誰的問題，以及是什麼問題。
要正確的認識問題，需要問兩個問題：
這是誰的問題？
有什麼問題？
能夠清晰的定義問題，是解決問題的第一步。
架構的切分的導火索是人、時間的負載太重。每個人的能力有限，或者單個人來做的話，時間太長。
架構的切分實際就是對stakeholder的利益進行切分或合併，使得每個stakeholder的權責是對等的，每個stakeholder可以為自己的利益負責。
架構切分的最終結果都會體現在組織架構上，只有這樣才能夠讓架構落地並推進。
架構切分的結果一定是乙個樹狀，這也是為什麼會產生分層。層數越多溝通越多，效率越低，分層要越少越好。盡可能變成一顆平衡樹，才能讓整個系統的效率最大化。
由此產出的一些設計算是軟體架構：
軟體因為流量增大而分拆成不同的執行單元，在不同的機器上部署所形成的架構，屬於軟體架構。
每個執行單元為了讓不同角色的人，比如前端，業務，資料儲存等能夠並行工作，所分成的**架構，也屬於軟體架構。
作者把架構歸結為分工的需要，但是只有乙個人的專案的時候，也是需要架構的。架構使整個系統滿足業務需求的基礎上，簡單、可維護。
架構漫談讀後感
應老師的推薦閱讀了由資深架構師王概凱 kevin 執筆的系列專欄 架構漫談 9篇文章遞進地講述了 討論什麼是架構 怎樣做好架構 軟體架構如何落地 如何寫好程式等問題，文章生動形象多次舉通俗的例子讓本來生澀的知識變得更加容易理解，感觸頗多。對這系列文章印象的較深的一點是 一直在挖掘一些本質的東西，對一...
架構漫談讀後感
花了一周的時間利用課餘的閒散時間，總算看完了王概凱的架構漫談，這九篇部落格從相對全面的角度對架構進行了概述。自己也對架構有了更深一層的認識。感覺作者在部落格裡提到的對架構的理解對我們初學者來講幫助其實很大。架構其實就是根據要解決的問題，對目標系統的邊界進行界定，然後對目標系統按某個原則進行切分，接著...
架構漫談讀後感
這學期新開設了軟體體系架構這門課，學這門課之前架構漫談的九篇部落格進行了閱讀，對這門課以及架構設計進行了初步的認識與了解。通過對這幾篇部落格的閱讀，首先需要明白什麼是架構，在最早期，每個人有自己的生活方式，人與人之間相互獨立，不相往來，隨著慢慢的發展，男女共同生活，也就出現了各自的分工，有的人做這個...