Ch7: 架構特性之範圍
在設計、測量、評估軟體的架構特性時，到底範圍應該要圈到哪邊?
為何需要探討架構特性的範圍
"建立演進式系統架構"這本書的作者在寫書時，
需要一個能夠為特定架構風格，測量其結構演進能力的技術，
但卻找不到任何能夠提供合適層級的量測方法
舉例，CC - 循環複雜度，像這樣程式碼層級的結構指標，只能揭露程式碼的低階細節，
沒有評估到程式碼之外的相依元件(例如資料庫)，
但這些元件相依性事實上會影響很多架構特性，
(特別是維運架構特性, e.g. 效能、可擴展性 etc...)
不管架構師花多大功夫設計一個高效或彈性的程式庫，
如果相依資料庫沒有跟上，那最終以application的角度來看，還是沒有達成這些架構特性
沒有正確理解與特定架構特性相關的範圍，就無法正確地為該架構特性進行對應的架構設計、量測架構特性的表現
架構特性範圍的演進
隨著軟體開發生態系的不斷快速的演進，對於架構特性範圍的普遍認知，已經不侷限在整個系統層級了
- 單體式: 架構特性位於系統層級
- 微服務: 架構特性的範圍已經變窄很多
所以窄的範圍是窄到哪邊(顆粒度-Granularity)? 怎麼看待整個系統中可再被細分的顆粒?
架構量子 Architectural Quanta
=架構特性之範圍
=架構特性的邊界
量子: 物理學上的定義為交互作用中最小單位的物理實體
架構量子就是在說明符合怎麼樣的特徵，可以形塑系統中的架構特性邊界
找出架構量子
具備高功能性內聚與同步共生性，能被獨立部署的 artifacts
能夠被獨立部署
- 一個架構量子包含所有必要的元件，使其能獨立於架構的其他部分運作
- 例如某個應用使用到資料庫，那資料庫就是量子的一部分，亦即使用單一資料庫部署的系統，就是擁有單個量子的架構
- 微服務架構，每個服務有自己的資料，那架構中就有多個量子
高功能性內聚
- 程式碼在目的性上的統一性有多好，好的統一性即滿足功能內聚性
- 高功能性內聚暗示該架構量子用來服務某個目的 (Problem domain)
- 在單體應用上，是否有高功能性內聚對架構量子構成無關緊要
- 但在微服務的架構下，通常設計上會展現高功能性內聚
同步共生性
- 分散式服務之間的溝通，採用同步呼叫的，則屬於同一個架構量子
- 如果有個服務同步呼叫另一個，則每個服務在維運架構特性上不太可能有太極端的差異，如果呼叫方比被呼叫方的擴展性好很多，逾時及其他可靠度方面的顧慮就會出現
心得:
以上只有提到以結果來看，滿足這些特徵，即形塑一個架構量子的邊界，但還沒有提到如何決定結果的樣貌
- 被劃分在同一個架構量子內的元件，需共同承擔被賦予的架構特性
- 一個架構特性能夠被正確展現的範圍，稱作架構量子
- 一個架構量子可以負擔自己的架構特性，換句話說就是一個架構量子可以跟另外一個的架構特性切開
這段最還還突然提到了"通信共生性"這個詞彙，但沒頭沒尾不知道從哪邊來的 ....????
細分架構量子的例子 (?)
付款與拍賣服務兩個微服務
- 同步共生性 (同一架構量子)
- 付款服務每500ms處理一筆付款
- 這樣當大型拍賣要結束的時候是不是很恐怖 - request timeout
- 非同步共生性 (不同架構量子)
- 可以讓兩個service以message queue這樣非同步的方式溝通來緩衝兩者特性的差異
- 非同步共生性建立的架構更靈活
DDD - 領域驅動設計
DDD是一種建模技巧，讓我們得以將複雜的問題領域進行有組織的"分解"，
Bounded Context，一個在DDD分解下的產物，這是認知到每個實體在局部化的背景下，方能有最佳表現
Before DDD，開發人員尋求的是組織內共有實體的全面復用，卻引發耦合、協調困難、複雜度增加等問題，
而 DDD 以 Bounded Context 的概念強調的是，不需要有一個組織統一共用的類別(例如客戶)，而是在每 Bounded Context 中創造自己的類別，在整合點再調和之間的差異即可
DDD的工程技巧讓架構量子(架構特性的範圍、架構特性的邊界)能以更系統化的方式被細分
架構量子的概念為架構特性提供新的眼界，在現代系統上，架構師是在量子層次而非系統層次定義架構特性。 透過在更精細的範圍內檢視重要的維運考量，架構師能儘早辨識架構上的挑戰，導向混合架構的採用
案例研究 - architecture kata
需求分析 -> 提取架構特性 -> 設計架構量子(邊界)
領域問題描述
描述
拍賣公司想把線上拍賣拓展到全國。
客戶選擇想參加的拍賣，等待拍賣開始，然後出價，
就好像跟拍賣商待在同一個房間一樣
使用者
每個拍賣可以擴展到容納幾百個、甚至幾千個參加者， 而且能同時進行的拍賣數目越多越好
需求
- 拍賣越即時越好
- 出價者用信用卡註冊、如果得標則系統自動扣款
- 必須透過信譽指數追蹤參加者
- 出價者能看到拍賣現場的視訊串流、以及所有即時的出價
- 線上及現場出價必須依照出價順序接收
額外背景
- 拍賣公司透過合併較小的競爭者積極地擴張
- 預算無限制，這是公司的策略方向
- 公司剛擺脫一項詐欺指控訴訟
提取架構特性
1. "全國"，"擴展到容納幾百個、甚至幾千個參加者，而且能同時進行的拍賣數目越多越好"，"拍賣越即時越好"
- 可擴展性 (要有能夠支援某個絕對數目的使用者)
- 彈性 (支援拍賣之突發特性、拍賣出價在即將結束時會變得比較狂熱)
- 效能 (滿足拍賣即時性的本質)
2. "出價者用信用卡註冊、如果得標則系統自動扣款"，"公司剛擺脫一項詐欺指控訴訟"
- Security
- 直接使用既有安全的信用卡處理技術不需要自創，只要開發人員不要把卡號存成純文字，並在傳遞時進行加密
- 針對詐欺事件，架構師應該要更深入了解
3. "必須透過信譽指數追蹤參加者"
- anti-trollability 反可控性 ???
- 可稽性 (auditability)、可紀錄性 (loggability)
- 領域特性 or 架構特性?
- 需要領域知識才能對其進行實作，或是他是一個抽象的架構特性
- 像彈性(處理使用者數目突發的能力)這種很明確的架構特性，可以純抽象討論架構特性，不管考慮的是哪種應用
- 信譽指數這個詞得先找個商業分析師、或相關主題的專家來解釋一下ㄉ
- 複習一下架構特性的三個準則，架構師要提取的架構特性必須是沒有涵蓋在領域當中，並且需要特別的軟體結構來達成
- 需要領域知識才能對其進行實作，或是他是一個抽象的架構特性
心得: 此需求能夠提取的架構特性並不明確，作者在這邊提醒分析架構特性只是整個應用程式開發的一小部分，不要顧此失彼
4. "拍賣公司透過合併較小的競爭者積極地擴張"
- 對應用程式的設計沒有立即的影響但有可能影響細節上的決策
- 沒有此特徵的公司，在選擇架構整合的通信協定更為自由
- 互通性 interoperatability
心得: 推測作者認為這個並非對應用程式成功至關重要的架構特性
5. "預算無限制，這是公司的策略方向"
- 架構師得以選擇更加精心設計或符合特定目的的架構
心得: 可以在架構特性上投資更多
6. "出價者能看到拍賣現場的視訊串流、以及所有即時的出價"，"線上及現場出價必須依照出價順序接收"
- 可用性
- 對可用性的要求對整個架構來說都是一致的嗎?
- 有沒有可能某個出價人的可用性比其他人都來得重要?
- 很明顯地，拍賣人對可用性的需求比起一般出價者要求更高，因為如果拍賣人上不了線，整個拍賣就無法進行了
- 可靠性
- 屬於維運面向, e.g. uptime, data integrity etc...
- 必須要考慮race condition等問題，確定出價訊息的順序是可靠的
- 這項需求，凸顯了檢視架構需要比系統層級更精細的範圍
提取架構量子
- 架構中不同的部分必須要有不同的特性：出價資訊串流、線上出價人、拍賣人是三個明顯不同的選擇。
- 架構師利用架構量子的概念，來思考部署、耦合性、數據應該放在哪裡以及架構內的通訊方式。
- 架構師可以根據每個架構量子分析不同的架構特性，進而能在早期進行混合架構設計。
在此案例中，辨識出以下的量子及其相應的架構特性
出價人回饋
包含出價串流及視訊串流
- 可用性
- 可擴展性
- 效能
拍賣人
現場的拍賣人
- 可用性
- 可靠性
- 可擴展性
- 彈性
- 效能
- 安全性
出價人
線上出價人與出價
- 可靠性
- 可用性
- 可擴展性
- 彈性
心得: 具備不同的架構特性的功能，暗示著在應用程式設計的時候，它們應該分屬不同的架構量子
Recap
- 架構量子為什麼對架構很重要?
- 假設一個系統由單一使用者介面及四個獨立部署的服務構成，每個服務有自己分開的資料庫。這個系統有一個或四個量子，為什麼?
- 假設一個系統有個管理靜態參考資料(例如產品型錄、倉庫資訊)的管理部分，以及管理下單的面向客戶部分。這個系統的量子數是多少，為什麼?如果你預見有多個量子，那麼管理量子與面向客戶的量子會共享資料庫嗎？如果是，那麼資料庫該放在哪個量子？