常見的如性能,安全性,可擴展性...etc各種"-ility"
在設計的時候可能會需要考慮多個,但是往往會有那一個最重要的"-ility"
找出最重要的XXXility
這本書就要額外加入一個不常被考慮的 — 可演進性(Evolvability)
一切都在演變,怎麼長期規劃?
- 例如這幾年Docker的容器應用
- 即便Linux夠用下作業系統的金錢成本歸零,但是DevOps的實踐(Puppet或Chef)自動供應機器帶來Linux運維成本歸零
- 所以將可變性植入架構中達成架構演進的動態平衡
有了架構還得防止它隨時間劣化
- 高階特性中的"可演進性"的副作用 →保護重要的架構特性
- 完成持續型架構
- 演進式架構定義:
演進式架構可支援橫跨多個維度且引導式的漸進變更
漸進變更
- 即團隊如何建構軟體及如何佈署
- 允許小規模的漸進變更的架構會比較容易演進(例如服務API的升級遷移)
引導式變更
- 即引導架構的變更
- 借進化計算(evolutionary computing)的適應度函數(fitness function)
- 適應度函數:"潛在的設計方案離既定目標有多遠"
- 每次軟體的變更的適應,透過一個或多個適應度函數以確保要保護的重要特性
多個架構維度
- 架構師不能只考慮技術架構
- 例如資料庫實體的結構關係會隨時間演進,過程中要額外考慮到安全性
- 所以單單資料庫牽涉到的軟體架構的可演進性牽涉的維度:
- 1.技術:架構的實作(框架,程式庫,實作語言等)
- 2.資料:schema(架構定義),資料布局,優化計畫等
- 3.安全性:安全策略,方針,找出缺陷的工具
- 4.運維/系統:簡單講就是基礎設施
- 以上將滿足(可擴展性,安全性,分佈,交易)
- 亦即架構師要考慮滿足多個"-ility"的維度進行演進
- 專案架構範圍=軟體需求+其他維度(或我理解的滿足各種維度)
- 架構是需求與其他維度組成,每個維度都被適應度函數保護
Conway定律
- Melvin Conway:設計系統的組織...產生的設計都被限制了,它們只是那些組織的溝通結構的複製品
- 技術人員將問題分解成更小的區塊來委託工作時即引入協調問題
- 在職能silo(穀倉)組織中是沒有考慮工程效率的
- i.e.有人想改變一樣東西,但那樣是別人擁有的,那人就很難改變它
- 例如過往我在金融業因專案提表單去與infra,資安做相關資源調整或申請
- 從格局上誇飾地來看
- 開發團隊就好像一間公司
- infra就好像另一間公司
- 資安也是一間獨立的公司
- 每間公司(團隊)間的溝通成本極大,完全不是夥伴的關係,甚至是對立的
- 所以漸漸有些公司改採服務邊界來組織團隊,團隊結構最好可以反映問題大小與範圍(逆Conway調度,Inverse Conway Maneuver)
- 簡而言之 →讓團隊結構符合目標架構
- 我想法上就是一個團隊有開發,有infra,有資安
- 團隊直接完全滿足上面專案提單的需求的商業與技術的每個層面
為何要演進?
- 架構師必須支援真正的變更而非臨時應急的解決方案
- i.e.作為架構師要關心的是整體的可演進系統
最後我不禁想起以前聽過公司核心轉換選商時的廠商Demo
是不是五年前那個使用hibernate的Java系統,且有中台的系統等等的架構圖
當一攤開來就已經代表已經沒用了!?
那架構圖只能用來應用財務等單位報帳使用!?
