1、架構模型解決的共同問題

1.1、高內聚低耦合：解耦外部依賴，分離業務復雜度和技術復雜度等。

1.2、信息孤島和數據壁壘：單體架構垂直，沒有相互調用和復用。邏輯抽象、能力下沉、多系統復用問題

1.3、熵增

2、?單體架構與分布式架構的核心區別在于

2.1、系統結構與部署

單體架構：一個代碼庫獨立部署，初始開發簡單，代碼臃腫w維護困難。

分布式架構：拆分為多個獨立服務，可獨立開發和部署，，

2.2、耦合度

單體架構：耦合程度高，維護困難。

分布式架構：服務拆分降低耦合度，提高開發效率

2.3、擴展性與性能

單體架構：擴展時需整體復制，資源利用率低。

分布式架構：按需擴展特定服務，適合高并發大數據處理。

3、業務系統的復雜性

業務系統的復雜性，可能來自于多個放面：

1、業務復雜性

2、技術復雜性

3、歷史負債，代碼腐化

無論是哪種情況帶來的復雜性，可以從下面幾個當面來熟悉復雜的業務系統：

1、梳理架構體系。業務架構、應用架構、數據架構（領域模型）、技術架構、部署架構構成整個系統的架構體系，缺一都會影響對系統的全局性認識個把控。

2、了解業務流程。這個其實在梳理業務系統的時候，核心的業務流程應該就已經覆蓋過了。但業務不只有核心流程，一些重要流程也是需要了解和梳理，有助于對系統更細致的了解。

4、屎山代碼/技術債

4.1、功能之間隱秘增加的耦合、

4.2、不可避免的代碼腐化

不可避免的代碼腐化是指在軟件開發過程中，由于需求的不斷迭代、技術債務的累積以及維護不善等原因，代碼質量逐漸下降，變得難以理解和維護的現象。

4.3、熵增

5、業務規模停滯結果(業務復雜度帶來的結果)

5.1、不斷地拓展產品的邊界，創造用戶價值

5.2、優化現有系統，提升用戶體驗。

5.3、好的技術架構和合理的模塊劃分方案，考慮到可復用性可以減少成本

6、軟件開發的增效

6.1、工程效能(業務開發占比和非業務開發占比)

6.2、運營提效

Essential Complexity(本質復雜性)

Accidental Complexity(偶然復雜性)

7、復雜度

7.1、業務復雜度

業務流程復雜，業務模型復雜，業務規則負責

7.2、技術復雜度

高并發，高可用，高性能

8、平臺與中臺的核心區別

平臺側重技術基礎設施的搭建，提供通用能力支撐；

中臺則強調業務能力的沉淀復用和新業務孵化，通過組織架構調整實現快速響應和創新支持。??

中臺和平臺都是某種共性能力，區分兩者的重點一是看是否具備業務屬性，二是看是否是一種組織。中臺是支持多個前臺業務且具備業務屬性的共性能力組織，平臺是支持多個前臺或中臺業務且不具備業務屬性的共性能力。

9、熟悉復雜的業務系統

1、熟悉業務流程

用戶是誰，提供的核心功能是什么？產品的邊界，產品族有哪些，系統的上下游調用關系。

2、梳理架構體系

業務架構，應用架構，技術架構，數據架構，部署架構。

不可避免的代碼腐化是指軟件開發過程中，由于需求的不斷迭代、技術債務的累積以及架構設計的局限性，代碼質量逐漸下降的過程。

當系統變得復雜，功能之間會逐漸產生耦合，它們的關聯關系也會變得復雜。這些無意間引入的耦合，會給后續所有的需求開發增加一些額外的負擔。

架構設計和模塊抽象只能面向當下，它天然是短視的或者說是有局限性的。

腐化除了來自開發者低質量的代碼，更核心的是來自于系統架構的腐化。

瀑布式開發：按順序開發，周期長。

敏捷開發：是部分開發，挑重點開發，因為開發是局部，不能統籌全局，所以當下的架構就會失效，出現代碼腐化。需求本身就是零散的，目標也是模糊的。在沒有全局視圖的情況下，架構自然就是有局限的，只能適應當下。而隨著項目的發展，只能適應當下的架構就會失效。

該分離的分離，該提取的提取，進行邏輯抽象，功能封裝，能力下沉，多系統復用。