第一章： 生命週期   


         我們常說的內聚這個概念，當我們找到了核心的生命週期後（拆分之後主體不變的子生命週期），核心的主體是不會變化的，也就是
核心業務的確定，這個東西是很難的變化的，而其他的非核心業務都是圍繞這個來走的。這是一個大的方向的內聚，如果說小的方向的內聚
就是我們的每一個生命週期的確定， 核心往往都是在一個類裡面定義生命週期的開始和結束的，這樣的話， 其他的業務都是圍繞這個方向來的，
 所有的控制也就都聚集在一個或者多個類中，這樣的話，其他的類呼叫的方法的時候，開始業務的時候，都是通過這個類來呼叫的，這樣的話，內聚的模式
 也就實現。 
 
核心業務和非核心業務的產生可以並行的，這樣的話，我們就可以進行模組化程式設計了，
 
        在理解非核心業務的時候，可以發現，真正核心的業務，往往都是不可以複製的，也就是說他都有各自的特性。所以，這樣一對比的話，非核心業務可以就是一個通用的方案， 不僅可以提供給自己的這個模組用，也許其他的模組也是可以用的。就是一個通用的服務了。這樣的話，通用的模組化程式設計也就出來了。同時這一塊的生命力也就更強大了。 
 
 
第四章： 什麼是架構


        架構的切分原則就是讓非核心生命週期獨立出來，便於不同的角色並行的開展工作。首先要在空間上進行拆分，使得空間上的管理可以並行，而時間上進行序列。
每一個切分出來的生命週期應該都是完整的，也就是一個獨立的模組，模組都是相互獨立和相互關聯的。這些模組的活動的結果都在改生命週期的主體上進行累積，這也就是內聚。
拆分出來的非核心生命週期應該都是圍繞核心生命週期，這樣的一個樹狀結構，也就是一個橫向的發展來進行和主體生命的溝通。這樣的溝通效率比較的高。
同時要明白，架構的拆分就是對業務模組的拆分，軟體的架構就是模擬業務的一個活動，更準確的說就是模擬人的一個活動的過程。 
拆分的原則就是把非核心生命週期拆分出來，有不同的角色來負責，讓人們可以並行的工作，每一個角色達到權責對等，並形成不同角色各自的激勵機制，
非核心業務的增長都是付出貢獻給核心業務，這樣核心業務收益的同時自己也收益。 

第八章：識別問題


        找出問題的主體， 是做架構的首要問題。


第九章：切分的原則


        因為維護自己的利益，是每個人的本性，每個人都逃避不了這一點。
每次政權的更迭，都是由不同的群體的利益重新分配的動力所推動並決定的。
沒人願意去損壞自己的利益，一旦去強制執行，人心就容易渙散。

第十四章：什麼是軟體架構


        業務問題的本質就是業務所服務物件的利益問題。
        通過對業務生命週期的拆分，突出並精簡業務核心生命週期，拆分出非核心生命週期，達到不同的生命週期在空間和時間上並行，便於不同的人同時開展工作，
提升業務人員的單位時間內的產出。


第十五章：什麼是軟體架構師
 
軟體的核心就是模擬人類的業務，而不再軟體的本身。
架構師思考技術時更多的考慮技術對生命週期拆分的支撐，以及不同技術實現拆分時落地的成本和收益。
技術人員要想成為架構師，必須跳出技術的視角，換一個角度去看技術，要把時間花在研究生命週期規律和業務的增長上，花在選擇合適的技術上，而不是隻是追求新潮的或資金喜歡的技術。
   
 
第十六章：業務，架構和技術三者的關係
  
        軟體是模仿人類的。
業務是核心，技術時解決業務問題的工具，而架構師讓業務長大的組織的方法。


第十八章： 軟體的架構拆分

        架構拆分的原則首先來源於業務自身的組織架構，使得軟體架構保持和業務組織架構的匹配關係，其次來源於軟體開發團隊自身的組織架構，最後來源於使用者的流量對軟體本身的衝擊。



第十九章： 如何寫好程式碼 


       內聚，是指某個生命週期的變化是累積在一個生命週期的主體上，而不是分散在不同的主體上。 
  從生到死之間的整個過程中，所發生的行為和狀態是累積在一個主體上的。
  注意：不能把業務模型當做資料物件來處理。

         業務模型關心的是其生命週期，資料是這些生命週期行為的狀態，所以黏合程式碼需要把業務模型轉換為儲存裝置的實體（Entity），實體和儲存裝置裡面的儲存粒度一一對應 跟隨著表的變化而去變化，這樣就保證了儲存裝置的變更不會影響業務模型。同業業務模型不能拿來用作服務和使用者之間的資料互動媒介，只能轉成DTO，也就是說業務模型對使用者是不可見的。這樣使用者的需要的展示的資料的變化並不會影響業務模型。同時這一塊也是變化的最頻繁的，這樣的話DTO就是很好的解決了這個問題了。 

 
   業務模型總是圍繞著核心生命週期展開的一個樹狀架構。 
 




第二十章： 單元測試
  
   單元測試程式碼保證程式碼的健壯性， 減少程式碼的BUG數。 
 
 
第二十一章： 軟體架構和麵向物件
 
  
   不同的程式碼人員也可以也分別關注同的生命週期（前提是物件已經封裝處理），並行的編寫程式碼，從而提升程式碼產出的效率，使得不同的程式碼人員之間不會互相干擾，這就是“內聚”產生的“鬆耦合”。
   
  
第二十二章： 軟體架構與設計模式   
  
  
 設計可以理解為一種有計劃，有目的的活動。
人們創造一個事物的過程總是先建設好事物的本身，在考慮如何更好地把業務和使用者連線起來。設計模式正好契合了連線使用者和業務的這個需要。
所有設計模式內部的分工其實是在模擬現實生活的分工；並且設計模式內部的分工往往更加的抽象，
模式只是關注到了共性，共性只會讓 解決問題變得更容易，更輕鬆，但是每個軟體的開發都是有自己的個性，這個個性也就是自己的獨特的業務能力。  
  
  

第二十三章： 軟體架構和軟體框架
核心部分是非常穩定的， 並且可以用在不同的軟體中，有些人把這些穩定的部分開元出來分享給社群，成為一個通用的解決方案。這類成熟的程式碼解決方案就是框架了。
框架基本上都是根據業務模型，設計模型，把模型中穩定的部分進行封裝，形成一個大的邊界，但是具體的內容留有自定義化。
  
  
第二十四章： 軟體運維
  
        問題： 監控， 自動化， 整合測試。 session如何共享。  分散式事物。


 
架構的認識：
 
  我們把更多的時間來處理核心的業務，這樣的話，提升生命週期的質量，從而使生命得到某種程度的延長，其實這也是人類社會的架構，和人類的進步。 
  架構的目的並非產生一個新的業務之外的新的東西出來，只是為了讓業務長得更加的高達強壯，服務更多的人，
 
 
  軟體是對人的模擬， 而建模實際上就是把人虛擬化， 把各業務系統負責人的工作用模型表達出來。模型中的每一個物件， 代表的就是現實生活中一個個活生生的人。
  這個物件的方法， 代表的就是這個人所負責的業務生命週期的行為。