在現實生活中，具備軟體架構師頭銜的人，大都是從軟體工程師成長出來的，這個出身已經決定了他們的主要關注點是在軟體和cs上。而要真正成長為乙個架構師，首先需要克服的就是時間困境。為什麼軟體工程師會對時間有恐懼和壓力呢？其原因是他們把按時完成自己的工作當成了自己的最大利益，並且對業務的不了解也會導致他們沒有太大的把握。這就要求軟體架構師把完成業務的工作當做自己的最大利益，深入到業務中去。隨著對業務的熟悉，對時間的恐懼才會慢慢地消失。
作為軟體架構師，必須時刻把軟體的生命週期和業務的生命週期的識別放在第一位，軟體生命週期的核心在於軟體執行生命週期，以及圍繞軟體執行生命週期的拆分和組織，業務生命週期的核心在於圍繞業務核心生命週期的拆分和組織。在**層面，要對業務**和訪問**做好架構拆分。架構師的核心在於架構的執行，軟體架構師必須是乙個組織的領導人，有權利調動這個組織的架構，才能更好地發揮架構師的作用，才能把軟體開發生命週期、軟體執行週期和業務生命週期的拆分落實執行。
技術人員對待不同技術是有區別的，往往是什麼技術流行就追什麼技術。技術人員也熱衷於創造新的技術，以對技術的掌握作為自己的標籤。也就是說技術人員對於技術是不平等的，而架構師則不一樣，無論是新的還是舊的技術，只要場景合適，他們都會採納。
架構師思考技術時更多地考慮技術對生命週期拆分的支撐，以及不同技術實現拆分時落地的成本和收益。以最少的成本達到更高的增長，是每個架構師追求的目標。
很多軟體工程師學了大量的演算法和計算機基礎，然而在工作中派不上用場，這時非常正常的。在業務領域，大多是如何解決現有的業務在軟體中模擬出來的問題，並沒有太多高深的數學問題。硬體成本的降低也讓我們不需要斤斤計較地摳時間和空間複雜度，這些都導致所學不能致用。
對於傳統企業而言，在軟體工程師慢慢理解並掌握了業務之後，慢慢就會看到傳統企業各種低效的地方，也會嘗試著去改變現狀。軟體和業務最終還是要合體的。當前軟體工程師專職於開發服務於業務的形式只是乙個過程，經過這個過程的普及，掌握業務的軟體工程師未來會更受歡迎。
迭代應該如何進行呢？迭代的前提是，必須要先確定優先順序，而理清楚業務的核心生命週期是最高優先順序，首先要實現業務的核心生命週期，剛開始可以簡陋一點，效率可以低一點，此時一般也不需要太多人參與，成本也不會太高。當業務人員或者使用使用者可以操作軟體之後，對軟體進行反饋，形成反饋環之後，軟體就可以通過一次次的迭代，豐富核心生命週期的功能。
要讓**容易維護，還要和業務一起長大，使得軟體架構容易隨著業務長大做出新的拆分，合併，並要保證其正確性。**主要由兩部分組成：
所以**又可以分為三部分，業務(business)部分來實現業務的邏輯，完成對業務生命週期的模擬。業務的狀態要靠儲存(repository)來實現儲存持久化。那服務(service)是用來做什麼的呢？
首先，由於計算機和軟體沒有自己的意志，因此其內部生命週期的變化就要由外部的人來推動，這時需要提供乙個訪問通道給外部的使用者，但如果把業務直接給使用者訪問，那麼使用者是很難和業務溝通的，因為這些專業術語，不是使用者能夠理解的。比如客戶去銀行，接待客戶的是更接近使用者語言的銀行櫃員，而不是銀行內部的專業業務人員。櫃員就是乙個服務，以使用者聽得懂的方式和使用者溝通，並把客戶的要求轉換成業務的語言，再由銀行內部的專業人員執行相應的操作，櫃員最後把執行的結果轉換為使用者的語言，為其服務。所以這裡服務提供的是乙個訪問通道，為使用者提供乙個容易訪問專業服務的訪問方式。那麼服務做為通道的含義是什麼呢？通道的意思是只負責呼叫業務邏輯，但不包含業務邏輯，這也意味著服務**中是不能包含業務邏輯的。
黏合**是什麼意思呢？業務邏輯屬於行為是沒有記憶的，而儲存屬於記憶是沒有邏輯的。要把行為和記憶黏合在一起，才能夠模擬乙個人。黏合**相當於是乙個具備行為和記憶的完整業務人，服務作為通道把黏合**和使用者聯絡起來。有些人會問，為何不把儲存掛在服務上，這樣黏合**就不需要了。但這樣相當於是讓銀行核心業務人員直接接待使用者。使用者的需求是變化最頻繁的，服務的方式可以避免頻繁的使用者需求變化對內部分工的衝擊。沒有服務的保護會導致使用者的需求直接衝擊儲存，而儲存非常脆弱必須保護起來。
還有人會問，為何不把儲存掛在業務上，這也是可以的。但這會讓關心業務模型的**人員，受到儲存的影響，必然無法專注於業務生命週期上。因此**就劃分出了以下責任：
1. 服務專注於使用者的需求，通過組織黏合**，也就是虛擬人所提供的生命週期活動完成需求。
2. 黏合**專注於管理業務中物件的生命週期，並且通過儲存儲存或載入業務中物件的狀態，實現對業務虛擬人的模擬。
3. 業務專注於實現業務的生命週期活動。
4. 儲存專注於資料的儲存和載入，並讓資料和儲存裝置的村儲存粒度一一對應。
分工之後大家需要的知識儲備可以減少一些，只要不同部分的開發人員互相商量好介面定義，不同部分的開發就可以並行地進行，不僅提公升了開發效率並且縮短了開發時間。
我們可以看到業務中的**是最重要的，服務與黏合**中的**起通道作用，這時為了讓使用者的請求能夠訪問到業務**。訪問邏輯的特定是組合**，即常見的順序呼叫，這種**中既不會有計算也不會有if else等判斷，用於組合下一層的節點所提供的功能，方便上一層節點的呼叫。
如果業務邏輯不是內聚的就會散落到很多其他地方去，那麼會造成哪些問題呢？
如果服務**中混入了業務邏輯，則服務做了兩件或者兩件以上的事情，服務本身的責任是訪問邏輯，這是順序執行，假如了業務邏輯就表明做了兩件或兩件以上的事情，可以分為以下兩種情況：
聊聊架構及架構師
b 1.架構分類 b 關於架構，大體可以分為以下三類 1.1 it架構 基於硬體 網路等構建整體的it運維架構體系，包括idc機房 網路拓撲 安全 負載均衡 運維監控等 1.2 基礎架構 1.3 應用架構 偏重於業務功能的實現，在基於使用者需求實現業務功能 提公升使用者體驗的基礎上，保證系統的效能 ...
聊聊架構閱讀筆記（1）
聊聊架構閱讀筆記 通過閱讀什麼是軟體，本書中提出軟體是以模擬人為目標。在軟體發展初期，軟體直接採用二進位制編寫，硬體和軟體成本都很高。隨著發展，軟體方面為了簡化難度，開始採用組合語言，進一步出現了類似人類語言的高階語言。軟體的出現，讓只有 身體 的機器具備了 大腦 機器通過更新 大腦 中軟體的方式不...
聊聊應用系統架構的0到1
沉迷於業務開發的你們，有沒有考慮過 使用者訪問到你開發的業務功能，到底經過了哪些環節 今天我將結合這些年的一些認知理解，開壇設法給大家講一講應用系統架構的從 0 到 1。01.如何造乙個大泥球？產品汪 緊急需求，2 天時間完成 x 的上線，包含知識問答頁面功能。程式猿 時間短，任務緊。一切以上線為目...