1.架構的定義
（1）根據要解決的問題，對目標系統的邊界進行界定。
（2）並對目標系統按某個原則的進行切分。切分的原則，要便於不同的角色，對切分出來的部分，並行或序列開展工作，一般並行才能減少時間。
（3）並對這些切分出來的部分，設立溝通機制。
（4）根據（3），使得這些部分之間能夠進行有機的聯絡，合併組裝成為乙個整體，完成系統目標的所有工作。
2.使用架構的原因：
（1）必須由人執行的工作
（2）每個人的能力有限
（3）每個人的時間有限
（4）人對目標系統由更高的要求
（5）目標系統的複雜性使得單個人完成這個系統，滿足條件（2）（3）
架構的出現使人們的工作分工更加均勻，工作完成效率更高，並且減少了工作完成的時間，節約了企業的成本，使得工作更夠有序的展開。
3.對於概念的深度理解
架構本質上使為人服務的，概念有時使對於物品的外表，特徵，用途，作用等一些方面行進的描述。這些都是我們可以看到的現象。但是我們對於使用更深層的理解是在我們的使用過程中獲得了哪些好處，解決了什麼煩惱，然後自己更加輕鬆愉悅或煩惱愁人等一些感性認識。使我們印象深刻的也是這些感性認識到的。
4.正確認識我們需要解決的問題
作者描寫了乙個妻子讓丈夫削土豆的例項，表明了不同的人之間對於乙個問題的認識程度是否相同有多麼重要。在團隊合作中，大多數情況下也是有乙個人去發布號令，分配任務，而其他人是服從分配。被分配任務的人只知道做好自己的任務，卻不考慮大局。等到任務都已完成，發現每個人的任務卻都整合不起來。
所以我們需要認識問題的本質。認識問題的本質最重要的是認識問題的主體。這個問題是對於誰而言。解決的這個問題的目標是什麼。問題大多數是為了解決人的煩惱，然後將自己於問題的主體中的人進行換位思考，這樣就能更加深刻的理解問題，看到問題的本質。
要正確的認識問題，需要問兩個問題：
（1）這是誰的問題？
（2）有什麼問題?
5.架構的切分
（1）架構的切分的導火索是人的負載太重。
（2）架構的切分實際就是對利益相關者的利益進行節分或合併，使得每個利益相關者的權責是對等的，每個利益相關者可以為自己的利益負責。
（3）架構切分的最終結果都會體現在組織架構上，只有這樣才能讓架構落地並推進。
（4）架構切分的結果一定是乙個梳妝，這也是為什麼會產生分層。層數越多溝通越多，效率越低，分層要越少越好。盡可能程式設計一顆平衡術，才能讓整個系統的效率最大化。
6.
架構師成為架構師的前提是能夠克服時間的恐懼和壓力，不再只專心完成自己的工作，二十將目標定為解決他人的問題。作為架構師必須正確認識到是誰的問題。認識問題之後，架構師還應該有自己的權力和義務。架構師應該有管理別人，調動組織架構的權力。架構師的義務就是發現問題，給出問題的解決方案。作為乙個架構師，懂得技術是架構師的基本能力，而在懂技術的基礎上去找到解決問題的方案。
7.從架構的角度寫好**
軟體架構包括了**架構。軟體實際上是對現實生活的模擬，虛擬化。所以我們的**應該分為幾部分。結合每個部署單元所承擔的責任，可以明確的拆分為兩個不同的責任：
（1）表達業務邏輯的**。
（2）對使用者提供訪問並儲存業務邏輯運送結果的**。
service**是最複雜的。把service拆分為三個部分，讓每乙個部分都能夠獨立的變化，這樣這三方的變化就不會產生連鎖反應，降低成本。這樣就劃分了幾個責任：
(1).service 就專注於 user 的需求，並組合 glue code 提供的服務完成需求。
(2).glue code 專注於組合 business 的呼叫，管理 business 裡面物件的生命週期，並且通過 repository 儲存或載入 business 的狀態
（3）.business 專注於實現業務的核心模型。
（4）.repository 專注於資料的儲存，並和儲存裝置一一對應。
邏輯業務的含義：在軟體**中，不需縮排和計算的順序呼叫，包括縮排的**目的是 catch exception 的，都不算邏輯，除此以外都是邏輯
9.技術與架構以及業務之間的關係
技術總是在人類解決對業務的要求不斷提高的情況下產生，目的也是為了獲取更大更好的利益。所以：
（1）技術是為了解決業務的問題而產生的，沒有了業務，技術就沒有了存在的前提。
（2）有了更好的技術，效率更差的技術，就會慢慢的被淘汰，消失，一切都遵從人類的利益訴求 -- 也就是業務。有人會問，不用鑽木取火了，但是弓弦加速轉動木棍還可以用啊？ 沒錯，因為弓弦轉動木棍這個技術，不是來生火的，是用來加速木棍轉動的，所解決的問題不一樣。但是兩種不同的技術，合理結合起來，會更好更有效率的解決業務問題。
所以技術與技術之間，有兩種關係：
（3）在解決同乙個業務問題的前提下，更高效，更低成本的技術，會淘汰低效，高成本的技術。這是人類利益訴求所決定的。
（4）一般剛開始解決根本問題的技術（鑽木取火）的效率是比較低的，只是把不可能變成了可能（從這一點上來說，技術才是業務的 enabler）。然後就會有提高效率的需求出現，要求改進這個技術。這個技術的低效率部分就會被其他人（或者技術發明人自己）加以改進，這部分就會形成新的技術。
《架構漫談》閱讀筆記
在每個人都必須自己完成所有生活必須品的生產的時候，是沒有架構的 當然在個人來講，同一時刻只能做有限的事情，在時間上還是可能會產生架構的 一旦產生的分工，就把所有的事情，切分成由不同角色的人來完成，最後再通過交易，使得每個個體都擁有生活必須品，而不需要每個個體做所有的事情，只需要每個個體做好自己擅長的...
《架構漫談》閱讀筆記
架構漫談是由資深架構師王概凱執筆的系列專欄，通過對其閱讀，我從中逐步認識到了什麼是架構，怎樣做好架構，軟體架構如何落地等內容。一 什麼是架構 在軟體行業，對於什麼是架構一直有很多的爭論。事實上，架構在軟體發明時的n多年以前，就已經存在了，這個詞最早出現在建築上。架構產生的五個動力可以概括為 由個人執...
《架構漫談》閱讀筆記
軟體架構師如何工作？不同於軟體工程中只需要編碼的 低階 碼農，一名合格的軟體架構師首先要對架構有深刻的理解。那麼什麼是架構？從建築的角度解釋，架構是計畫 設計和建造建築物 物理結構的過程和生產活動。從這個定義上看，架構像乙個過程，但又不明確。為了弄清這個問題，我們首先要了解為什麼會產生架構？在最早期...