一、「architecture is like teenage ***,everybody talks about it,nobody really knows what is it.」
「architecture is both the process and the product of planning,designing,and constructing buildings and other physical structures」
把乙個整體切分成不同的部分，由不同角色來完成這些分工，並通過建立不同部分互相溝通的機制，是的這些部分能夠有機的結合為乙個整體，並完成這個整體所需要的所有活動，這就是架構。
架構產生的動力（原因），當系統規模達到一定程度：
1）必須有人執行的工作。（無需人工介入，也意味著不需要改造，也就不需要架構了）
2）每個人的能力有限。（分工細緻，所能專注的事情有限，需要協同）
3）每個人的時間有限。（系統工程需要有限時間內完成）
4）人對目標系統有了更高的要求。（提公升，是推動架構變革的源動力）
5）目標系統的複雜性使得需要多人完成。
架構就是：
1）根據要解決的問題，對目標系統的邊界進行界定。（解決有限問題，而非無限延展的問題）
2）並對目標系統按某個原則的進行切分。切分的原則，要便於不同的角色，對切分出來的部分，並行或者序列的開展工作，一般並行才能減少時間。並對這些切分出來的部分，設立溝通機制。
3）根據3，使得這些部分之間能夠進行有機的聯絡，合併組裝成為乙個整體，完成目標系統的所有工作。
二、架構實際上解決的是人的問題，而概念是人認知這個世界的基礎，自然改變的認識就非常的重要。
根據架構的定義，要做架構所首先必須具備的能力就是能夠正確的認識概念，能夠發現改變背後所代表的問題，今兒才能夠認識目標領域所需要解決的問題，這樣才能夠為做好架構打好基礎。
做好架構首先需要做的就是是識別出需要解決的問題。一般來說，如果把真正的問題找到，那麼問題就已經解決80%了，這個能力基本上就能決定架構師的水平。
找到問題的主體，是做架構的首要問題，我們要解決的問題，一定都是人的問題。更進一步，架構師要解決的，基本都是別人的問題，不是自己的問題。我們一定要明白，任何找上架構師的問題，絕對都不是真正的問題。為什麼呢？因為如果是真正問題的話，提問題過來的人肯定都能夠自己解決了，不需要找架構師。架構師都要有這個自覺：發現問題永遠都比解決問題來的更加重要。（解決方案，不是問題的主體；比如使用者需要一把錘子，這是解決方案，不是問題主體，問題的主體是「使用者需要錘子解決什麼問題？」）
三、架構切分
切分的本質就是利益的調整；切分的幾個原則：
1）必須在連續時間內發生的乙個活動，不能切分。比如孕婦懷孕，必須要10月懷胎，不能切分成10個人乙個月完成。
2）切分出來的部分的負責人，對這個部分的權利和義務必須是對等的。如果權利和義務不對等的話，會傷害每個人個體的利益，分出來執行的效率會比沒有分出來的還要低，實際上也損害了整體的利益，這違背了提公升整體利益的初衷。（利益相關者）
3）切分出來的部分，不應該超出乙個自然人的負載。
4）切分是內部活動，內部無論怎麼切分，對整個系統的外部應該是透明的。如果因為切分導致整個系統解決的問題發生了變化，那麼這個變化不屬於架構的活動。
所有的架構分拆，都應該是形成樹狀的結果，不應該變成有向圖，更不應該是無向圖。很多人談架構，必談分層，但是基本上都沒有意識到，是因為把乙個整體分拆為一棵樹，因為有了樹，才有層。
實際上切分的過程就是建模的過程，每次對大問題的切分都會生成很多小問題，每個小問題就形成了不同的概念。
任何架構調整都會涉及到組織架構，千萬不可輕視。同樣，如果對於stakeholder的利益分拆不夠透徹，也會導致架構無法落地，因為沒有人願意去損害自己的利益。一旦強制去執行，人心就開始潰散。這個也不一定是壞事，只要滿足原則2）就能夠很好的建立乙個新的次序和新的利益關係，保持組織的良性發展，長久來看是對所有人的利益都是有益的，雖然短期內有對某些即得利益者會有損害。
四、架構師的前提條件：
如果乙個人在工作中，只是致力於完成自己的工作，已做好自己的工作為主要目標，那麼最多只能成為乙個工匠，無法成為一名架構師。因為這個過程解決的還是自己的問題。當我們所做的工作處於社會分工的一環，需要幫助別人解決問題，並且按時解決別人的問題成為我們自己的問題的時候，我們就有了時間壓力，潛意識裡就會自然而然的有一種對時間的恐懼。這個恐懼在潛意識裡會想方設法推動我們採用各種手段，以便及時的完成工作。
要成為架構師，必須要超越這個恐懼才能看清楚，我們要解決的是別人的問題，不是自己完成工作的問題。因為僅僅完成了自己工作的問題，也並不一定就解決了別人的問題。
「如果問題不解決，究竟誰會有利益損失？如果問題解決了，究竟誰會有收益，誰的收益最大？」回答了這兩個問題，我們就能找到「問題」的主體。
架構師必須是乙個組織的領導人，有權利調動這個組織的架構，才能夠更好的發揮架構師的作用，更好的把利益的調整落到實處。所以很多公司設立了很多架構師職位，但是並不具備調動組織架構的權利，那麼這個架構師的職位一定是形同虛設。架構師只能夠通過建立某種流程來形式架構師的權利，比如強制架構review，反而會造成很多內部不必要的衝突，最終都會導致這些流程流於形式，得不償失。相信很多人都已經經歷過這些，但似乎很少有人回去**這是為什麼。
所有架構的核心就是組織架構。或者也可以這麼說，乙個合格的組織領導人，一定必須是乙個合格的架構師。
五、技術與架構、業務之間的關係
技術是為了解決業務的問題而產生的，沒有業務，技術就沒有了存在的前提。
1）在解決乙個業務問題的前提下，更高效，更低成本的技術，會淘汰低效、高成本的技術。這事人類利益訴求所決定的。
2）一般剛開始解決根本問題的技術效率比較低的，只是把不可能變成了可能。然後就會有提高效率的需求出現，要求改進這個技術。
不同的技術，通過樹狀結構，組合在一起，形成乙個完善的架構解決方案，共同完成業務的目標，這就是技術、業務和架構的關係。
讀漫談架構
六 軟體架構到底要解決什麼問題？要解決誰的問題？軟體實際上就是把現實生活模擬到計算機中，並且軟體是需要在計算機的硬體中執行起來的。需要解決的問題 一 業務問題 具體的現實生活狀態中，沒有軟體的時候，所解決的問題的主題是誰，解決的是什麼問題，是如何解決，如何運作的？二 計算機問題 1.如何模擬？2.硬...
重讀《架構漫談》
一直以來，在軟體行業，對於什麼是架構，都有很多的爭論，每個人都有自己的理解。甚至於很多架構師一說架構，就開始談論什麼應用架構 硬體架構 資料架構等等。我曾經也到處尋找過架構的定義，請教過很多人，結果發現，沒有大家都認可的定義。套用一句關於big data流行的笑話，放在架構上也適用 architec...
《架構漫談》有感
人對事物的認識不是僅僅通過文字描述就足夠的，紙上得來終覺淺，絕知此事要躬行。我們程式設計師更是這樣，沒有 的積累怎麼能有寫軟體的能力。今天讀了架構漫談，說實話看到第四篇時我還不知道架構到底是什麼東西。在我的認識裡架構就是自己以前編的功能模組，它可以實現一定的功能，拼接起來就是乙個完整大軟體。架構漫談...