1. 域和服務
1.1. 域是你正在為其構建的現實世界主題區域
1.2. 服務是一組功能，其目標是完成一項任務
1.3. 一個域可以包含多個服務
1.4. 確定領域中應包含的內容
-
1.4.1. 確定領域應該包含什麼以及要包括哪些服務時，最好的建議是簡單地去與使用者和利益相關者交談，傾聽他們在說什麼，並構建將幫助他們完成工作的服務
-
1.4.2. 要避免在真空中進行架構設計的經典陷阱
2. 可擴充套件性
2.1. 允許我們增加系統的容量以提高效能和處理需求
2.2. 單臺機器上可能的資源有硬性限制
3. 彈性
3.1. 一個可擴充套件系統動態擴充套件的能力
3.2. 一個高彈性的系統可以根據當前的工作負載自動擴容和縮容
3.3. 隨著需求的增加，擴大規模至關重要，而縮小規模則可以在雲環境中節省資金
3.4. 現代系統有時會縮放到零，這意味著它們可以在空閒時自動關閉
3.5. 動態縮放有助於在沒有工程師手動干預的情況下確保足夠的效能
- 3.5.1. 彈性提高可靠性
4. 可用性
4.1. IT服務或元件處於可操作狀態的時間百分比
4.2. 單機通常無法提供高可用性和可靠性
5. 可靠性
5.1. 系統在指定時間間隔內執行其預期功能時滿足規定標準的機率
5.2. 低可靠性會導致低可用性
6. 分散式系統
6.1. 利用分散式系統來實現更高的整體擴充套件能力以及更高的可用性和可靠性
6.2. 水平擴充套件允許你新增更多機器以滿足負載和資源需求
6.3. 水平擴充套件系統有一個主節點，作為工作負載例項化、進度和完成的主要聯絡點
6.4. 典型的現代分散式架構也內建冗餘
6.5. 分散式系統的管理細節通常被抽象出來，使你可以專注於高階架構而不是低層次管道
7. 緊耦合與松耦合
7.1. 緊耦合
-
7.1.1. 可以選擇擁有較為集中的依賴項和工作流
-
7.1.2. 領域和服務的每個部分都非常依賴於其他領域和服務
7.2. 松耦合
-
7.2.1. 擁有分散的領域和服務，它們彼此之間沒有嚴格的依賴性
-
7.2.2. 在松耦合的情況下，分散的團隊很容易構建其資料可能無法被同行使用的系統
-
7.2.3. 確保為擁有各自領域和服務的團隊分配共同的標準、所有權、責任和義務
7.3. 設計“好的”資料架構依賴於領域和服務的緊耦合和松耦合之間的權衡
8. 架構層次
8.1. 單層
-
8.1.1. 在單層架構中，你的資料庫和應用程式緊耦合，駐留在單個伺服器上
-
8.1.2. 該伺服器可以是你的膝上型電腦或雲中的單個虛擬機器(Virtual Machine，VM)
-
8.1.3. 緊耦合的性質意味著如果伺服器、資料庫或應用程式出現故障，則整個架構都會失敗
-
8.1.4. 單層架構適用於原型設計和開發，但由於明顯的故障風險，因此不建議將其用於生產環境
-
8.1.5. 單層架構適用於在本地計算機上測試系統，但不建議用於生產用途
-
8.1.6. 單層架構提供了簡單性，但也有嚴重的侷限性
8.2. 多層
-
8.2.1. 透過解耦資料和應用程式解決了緊耦合單層架構的挑戰
-
8.2.2. 多層（也稱為n層）架構由單獨的層組成：資料、應用程式、業務邏輯、展示等
-
8.2.2.1. 將資料與應用程式分離，並將應用程式與展示分開
-
8.2.3. 這些層是自底向上和分層的，這意味著下層不一定依賴於上層
-
8.2.3.1. 上層依賴於下層
-
8.2.4. 三層架構由資料層、應用程式/邏輯層和表示層組成
-
8.2.4.1. 每一層都相互隔離，允許關注點的分離
-
8.2.4.2. 使用三層架構，你可以在每一層中自由使用你喜歡的任何技術，而無須集中精力
-
8.2.5. 資料工程師應該使用層來評估他們的分層架構和處理依賴關係的方式
-
8.2.5.1. 考慮你是否希望節點出現資源爭用
> 8.2.5.1.1. 如果不是，則使用無共享架構：單個節點處理每個請求，這意味著其他節點不與該節點或彼此共享記憶體、磁碟或CPU等資源
- 8.2.5.2. 節點是否應該共享所有節點都可以訪問的相同磁碟和記憶體
> 8.2.5.2.1. 共享磁碟架構
8.3. 單體
-
8.3.1. 單體內部的耦合
-
8.3.1.1. 技術耦合
> 8.3.1.1.1. 技術耦合指的是架構層次
- 8.3.1.2. 領域耦合
> 8.3.1.2.1. 領域耦合指的是領域之間耦合在一起的方式
-
8.3.2. 單體在技術和領域之間具有不同程度的耦合
-
8.3.3. 單體的緊耦合意味著其元件缺乏模組化
8.4. 微服務
-
8.4.1. 微服務架構包括獨立的、分散的和松耦合的服務
-
8.4.2. 每個服務都有一個特定的功能，並且與在其領域內執行的其他服務解耦
-
8.4.3. 單體不是一蹴而就的，它是一個技術問題，也是一個組織問題
8.5. 注意事項
-
8.5.1. 中央資料倉儲本質上是龐大的
-
8.5.1.1. 向與資料倉儲等效的微服務的轉變是將擁有特定領域資料管道的工作流連線到相應的特定領域資料倉儲進行解耦
-
8.5.2. 務實地將使用松耦合作為一種理想，同時認識到你在資料架構中使用的資料技術的狀態和侷限性
-
8.5.3. 以垂直方式將架構的元件分為不同的關注層
-
8.5.4. 集中化：一個團隊負責從所有領域收集資料並協調它以供整個組織使用
-
8.5.5. 資料網格
-
8.5.5.1. 使用資料網格，每個軟體團隊負責準備其資料以供組織的其他部門使用
-
8.5.6. 單體不一定是壞的，在某些條件下從單體開始可能是有意義的
-
8.5.6.1. 從單體開始要簡單得多
-
8.5.6.2. 準備好最終將其分解成更小的部分
9. 使用者訪問
9.1. 多租戶
-
9.1.1. 所有云服務都是多租戶的，儘管這種多租戶出現在不同的粒度上
-
9.1.1.1. 雲端計算例項通常位於共享伺服器上，但虛擬機器本身提供了一定程度的隔離
-
9.1.1.2. 物件儲存是一個多租戶系統，但只要客戶正確配置其許可權，雲供應商就可以保證安全性和隔離性
-
9.1.2. 工程師經常需要在更小的範圍內做出有關多租戶的決策
-
9.1.2.1. 來自不同租戶的資料必須適當隔離
-
9.1.2.2. 資料隔離策略因系統而異
-
9.1.2.3. 必須確保檢視不會洩漏資料
10. 事件驅動架構
10.1. 一個事件驅動的工作流包含在資料工程生命週期的各個部分建立、更新和非同步移動事件的能力
10.2. 主要領域
-
10.2.1. 事件生產
-
10.2.2. 路由
-
10.2.3. 消費
10.3. 事件驅動架構的優勢在於它將事件的狀態分佈到多個服務中
11. 棕地專案
11.1. 棕地(Brownfield)專案通常涉及重構和重組現有架構，並受到現在和過去的選擇的限制
11.2. 最好是深入挖掘、提出問題並理解做出決策的原因
11.3. 同理心和上下文在幫助你診斷現有架構的問題、發現機會和識別陷阱方面大有幫助
11.4. 直接重寫的一種流行替代方法是絞殺者模式：新系統緩慢地、逐步地替換遺留架構的元件
11.5. 如果你在一個大型組織中，根除遺留技術或架構可能是不可能的
12. 綠地專案
12.1. 綠地(Greenfield)專案讓你開創一個全新的開始，不受先前架構的歷史或遺留問題的限制