###### tags: `無瑕的程式碼：整潔的軟體設計和架構篇`

# 15什麼是架構

* 軟體架構師:
1. 軟體系統的架構是建置系統者賦予系統的樣貌(shape)
3. 目的是為了使軟體系統的開發、部屬、運行和維護都更便利
1. 不要落入"建議軟體架構師從程式碼中撤離，專注更高層次的問題"的陷阱

## 開發
* 一個系統的架構應該使這個系統易於開發
* 小團隊
> 團隊太小，不想要有上層結構的障礙
* 大團隊(5個不同團隊，每個團隊包含7人以上)
> 劃分具有可靠又穩定的介面的"定義明確的元件"，否則很難走下去

## 部署
1. 必須是可部屬的。部屬成本越高系統就越不實用
2. 開發初期很少考慮到部屬策略，導致設計出易於開發但很難部屬的系統架構

## 運行
1. 運行對於架構來說影響不如 開發、部屬、維護的大
2. 運行效率可由增加更多的設備來解決，因為硬體便宜而人員昂貴
3. 話雖如此，一個好的軟體架構傳達了系統的運行需求
> 使用案例use cases、系統的特性features、案需行為required behaviors升等為頭等實體，對於開發人員，那就是個可看出來的目標

## 維護
1. 維護的主要成本是探礦和風險
> 探礦(spelunking): 試圖找出增加新特性或修復缺陷的最佳位置和最佳策略而開挖現有軟體"所需付出的代價"
2. 將系統分離成元件群，並透過穩定的介面隔離這些元件，可以為了將來的特性照亮路徑，並大大降低意外破壞的風險

## 保持選項是開放的
1. 行為的價值和架構的價值，後者價值較大
2. 策略(policy)和細節(details)，
> 策略:體現了所有的業務規則和程序
> 細節:包含IO設備、資料庫、Web系統、伺服器、框架、通訊協定等等

## 設備獨立
舉例:IO設備抽換，可指定輸出設備是讀卡機、磁帶、或任何其他單元紀錄的設備。(開放-封閉原則)

## 垃圾廣告信
客戶寄大量的信件，並提取信件中的姓名、地址和其他元素列印在表單中。但因IBM360租金太貴，想改用磁帶取代行列式印表機
> 策略:姓名、地址紀錄的格式

> 細節:設備抽換

## 物理定址
> 硬碟有200個磁柱，每個磁柱有幾十個磁區/可讀寫表面，將Agent，Employer，Member寫入指定磁區(硬編碼在業務邏輯無所不在)。若更換新的硬碟後，需要修改程式碼

> 解決方式:定址方案改成相對位址，寫一個位址轉換的副程式

## 總結

優秀的架構師會小心的將細節從策略中分離出來，使策略與細節徹底脫鉤，使策略不了解細節，不以細節為依據

# 16獨立性

## 使用案例

架構必須支援使用案例(use cases)
> 如果系統是購物車應用程式，那麼架構必須支援購物車的使用案例

## 運行
> 如果系統必須每秒處理100000個客戶，架構必須支援對應的產量(throughput)和回應時間(response time)

> 如果系統必須以毫秒為單位查詢大數據cube，那麼架構必須打造允許這類型的運行

## 開發

Conway法則，促使各團隊可以獨立行動，不會互相干擾。透過將系統正確分割成完全隔離的、可獨立開發的元件來實現
https://zh.wikipedia.org/zh-tw/%E5%BA%B7%E5%A8%81%E5%AE%9A%E5%BE%8B

## 部署

目標:立即部屬
* 一個好的架構不會依賴於幾十個小的設置腳本和屬性檔案的微調。
* 良好的架構有助於系統在建置後立即部屬

## 讓選項保持開放

良好的架構在必須改變的各個方面，都透過選項開放，使得該系統易於改變

## 解耦各層

UI層、特定的業務規則(驗證邏輯/計算帳戶利息/庫存盤點等)、獨立於應用程式之外的業務規則、資料庫層 等等

## 解耦使用案例

EX:新增訂單、刪除訂單

## 解耦模式

為了得到運行上的好處，解耦就必須有適當的模式(mode)
服務或微服務
s3算吧?

## 獨立開發
* 層次與使用案例解耦
> 層次:UI與業務規則
> 使用案例:addOrder與deleteOrder分離

## 獨立部屬

使用案例和層次的解耦也為部屬提供了高度的靈活性
1.只部屬Web
2.只部屬Service

## 重複

1. 如果他們以不同的速率並且由於不同的原因改變，那就不是真的重複
2. 重複的程式碼應該要提出來共用

## 解耦模式(再次解釋)
1. 原始碼層級:改code
2. 部屬層級:jar Gem DLL
3. 服務層級:透過網路封包傳遞(微服務)

## 總結

一個系統的解耦模式，也是可能隨時間而改變的，一個好的架構師會預見並適當地次使這些變化發生。