## 策略和層級

### 層級
+ 定義:與輸入及輸出的距離
+ 高層級的程式碼不應該直接依賴於低層級的程式碼

## 業務規則
+ 關鍵規則、關鍵資料是密不可分的，將其稱為實體

### 實體
+ 使用案例是特定單一應用程式，更接近輸入輸出，所以是比較低層級的
+ Entity是高層級的，因為可以在許多不同的應用程式中使用，離輸入輸出更遠。

## 會尖叫的架構

### 架構的主題
+ 架構不是基於框架的，框架是使用對象。

### 架構的目的
+ 計畫能滿足使用案例

### 但是Web呢
+ 他只是一個IO設備，不應該用他決定你的架構細節

### 可測試的架構
+ 如果架構全部關於使用案例，且對框架保持一定的安全距離，那應該可以在沒有框架的情況下對案例進行單元測試，

## 整潔的架構

### 特徵
+ 獨立於框架
+ 可測試
+ 獨立於UI
+ 獨立於資料庫
+ 獨立於任何外部代理

### 依賴規則
+ 原始碼依賴關係只能指向內部，朝向更高層級的策略

### 實體層
+ Entity 封裝了業務規則，可能是具有方法的物件，或是一組資料結構及函式，任何應特定應用程式的操作改變都不會影響實體曾

### 使用案例層
+ 包含了應用程式特定業務規則，封裝了使用案例，個人感覺像是laravel常用的service pattern

### 介面轉接層
+ 將資料從最適合於使用案例和實體的格式轉換為適合外部代理的格式，像是Controller、Presenter之類的

### 框架和驅動層
+ 通常由框架和工具組成(ex: 資料庫和Web框架)

### 一個典型的場景

+ 圖22.2，遵循了依賴規則，所有依賴關係跨越邊界都是指向內圈的

## Presenter與Humble Object
### Humble Object模式
+ 一種幫助人將難以測試行為與易於測試行為隔離開來的一種方式，

### Presenter 及　View
+ View很難測，所以我把用Presenter把裡面的邏輯拆出來方便測試

## 部分邊界
+ 為全部的架構作邊界代價可能過高，所以會折衷為邊界保留一些彈性
+ 把所有可以獨立編譯、部屬元件所需的所有工作都放在同一個元件中
+ Facade模式就是一個範例

## 層與邊界
+ 舉了如果要為簡單的程式做出一堆架構與邊界要花費多少時間精力
+ 過度的設計比不足的設計還要糟

# QA
+ 你認為哪些規則應該封裝在使用案例，而哪些應該封裝在實體?
+ 在設計架構時，如何在保持架構的簡潔和避免不必要的複雜度間做出選擇?