架構就是上下文 - Eltjo
Eltjo Poort 是 CGI 荷蘭的架構實踐負責人,在軟體行業擁有超過 30 年的經驗。
Eltjo 首先解釋了架構上下文和業務驅動程式的重要性,它們可以幫助架構師理解不同的權衡和選項,以便做出正確的架構決策。
Eltjo 分享了架構師的主要職責,以及架構師應如何通過了解架構文件的不同目標來避免編寫又大又長的架構文件。
架構是上下文
- 當你學習軟體設計時,你會學到很多好的設計原則。您知道,根據思想流派的型別,您要麼學習如何將新系統的職責分解為幾個元件,要麼學習如何檢視共同職責並設計類和物件以及它們之間的關係。並且有很多好的設計原則,比如資訊隱藏,或低耦合和高內聚。
- 但是,對我而言,如果您不只是關注這些通用的、良好的設計原則,而是真正關注應用它們的業務環境上下文,它就會成為架構。
- 我認為你實際上需要注意的是在這個特定上下文的系統中,在這個具有這些特定業務驅動的環境上下文中。你做出的每一個設計選擇都有替代方案。只有瞭解上下文驅動的這個因素,才能在這些備選方案之間做出正確的權衡。這些可以是商業驅動。這可能是時間壓力。他們可以是技術驅動力。
- 作為一名架構師,你不應該躲在你的象牙塔裡,只做偉大的設計,因為你做不到。如果您不與業務人員或業務利益相關者以及可以告訴您在這種特定情況下什麼是重要驅動因素的技術利益相關者交談,您就無法做出正確的權衡。
瞭解業務驅動力
一個好的架構師需要一直問業務 "為什麼?"。僅僅知道業務需要什麼,還不足以做出正確的權衡。你需要知道他們需要它的原因,因為這才是真正的架構驅動力所在。
除非我們知道原因,否則我們無法幫助他們做出這個決定。是的,他們當然會說我們想要一切。但他們只是說他們想要所有的東西,因為他們沒有意識到其中的利弊。他們做出的每個選擇都有缺點,我認為我們的工作是向他們指出這些缺點。具體來說,就是用他們的語言指出這些缺點和這些權衡。
如果我們說你對這種特定的方式有偏好,但它會導致一個更復雜的系統,你就無法說服他們。他們並不擔心繫統會更復雜。他們說,那是你們的工作。你是建築師,對嗎?你是技術人員。所以你要處理複雜的問題。
你需要把這種複雜性轉化為它對業務的意義。
一個更復雜的系統意味著它可能需要更多的人去控制複雜性,所以它將會更昂貴。
但是,對於商業人士來說,也許更有趣的是它實際上增加了錯誤的風險。因為在一個更復雜的系統中,我們不可能總是監督一個特定變化的全部影響。一個看似簡單的變化實際上可能會影響到很多其他元件,這意味著更多的工作。因此,再一次,更昂貴。
但是,也有更多的風險,因為有額外的依賴關係,我們可能會錯過一個依賴關係,或者一個介面可能會發生我們不知道的變化,等等。
如果我們把這些權衡轉化為商業術語,那麼我們就可以幫助他們參與決策,做出正確的架構選擇,正確的設計選擇,而不是僅僅因為他們想要所有的東西卻不瞭解所有的東西而感到惱火。
不正確的架構決定
談到糟糕的決定或過去遺留的決定,實際上不可避免地要做出一些事後可能被證明不是最優的決定。
[Philippe Kruchten]說,軟體架構師的生活是一個漫長的、有時是痛苦的、部分在黑暗中做出的次優決定的連續過程,這讓人感到沮喪。為什麼架構師時常會做出事後證明是錯誤的決定呢?這與作為一個架構師必須做出的決定的順序有關。
基本上,它歸結為你必須在你擁有最少事實知識的時候做出最重要的決定。當然,你會盡一切努力來避免這種情況。你試圖保持你的選擇開放。你試圖推遲你的決定,直到實際上進一步推遲會破壞事情,或者會使人們不能再工作的時間點。當然,你嘗試一切辦法來推遲決定,直到你有更多的知識。
然而,你必須先做出最重要或最有影響的決定。因為你所做的每一個決定都會制約你以後在同一設計空間中必須做出的所有其他決定。所以,你的架構決定,會減少你的設計空間。它們減少了你以後的選擇。
而你不希望的是,一個低影響的決定和不重要的決定製約了你的選擇,使你以後不得不做出更多的高影響的決定。這實際上是以錯誤的方式進行的。所以你必須先做最重要的決定,因為你想讓高影響的決定製約低影響的決定,而不是反過來。
這意味著,無論你做什麼來保持你的選擇,到最後,你最終做出的決定,實際上如果你在兩個月後知道的話,你會以不同的方式來做。所以這就是為什麼不可避免地會陷入那種情況。你有時會做出一個錯誤的決定。你必須接受這一點。
瞭解架構的權衡
這需要採取一些步驟。當然,首先你需要了解這些需求,以及它們是如何相互衝突的。有些需求永遠不會衝突,比如功能需求,我們希望系統做什麼。要麼他們必須做這個,要麼他們必須做那個。它們不會發生衝突。
但是,衝突實際上出現在其他需求中。那些不僅僅是關於普通功能的需求,我們通常稱之為非功能需求,但實際上更好的名稱是質量屬性需求。這些是像效能或可修改性或可用性等的東西。這就是架構權衡的地方。
還有一類非功能需求,或者有些人稱之為約束條件,這與按時交付或與特定人群一起建立軟體有關。
而這些都是真正推動架構決策的東西。僅僅是單純的功能,功能需求驅動架構的情況非常罕見。所以,你必須瞭解這一點,你必須瞭解這些非功能驅動因素是什麼。
然後,當然,你也必須知道你有哪些不同的選擇。如果你不得不做出決定,去選擇你認為只有一種選擇的東西,或者只有一種選擇,那就不是決定。決定是如果你有幾個選擇。因此,為了做出正確的決定,你還需要確保你知道你有哪些選擇。
更多點選標題
相關文章
- 我懂了,原來這就是4+1架構模型!架構模型
- 在阿里架構師眼中構建一個較為通用的業務技術架構就是如此簡單阿里架構
- 沒錯,這就是【石杉的架構筆記】立下的2019年FLAG!架構筆記
- 資深架構師Sum的故事:正則!入門就是這樣簡單架構
- 架構之:serverless架構架構Server
- 【細品架構4/100】架構之架構切分架構
- SaaS架構:流程架構分析架構
- 上下文 Context 與結構體 StructContext結構體Struct
- 架構師修煉之道(二)——架構?設計?架構師?架構
- 單體架構&微服務架構&中臺服務架構架構微服務
- 單體架構到垂直架構架構
- 架構之:資料流架構架構
- 前端架構之小小node架構前端架構
- 架構架構
- MySQL 高可用架構之 MMM 架構MySql架構
- 【架構分析】MESA (EGL/GLES)架構分析架構
- 架構之:軟體架構漫談架構
- 架構之:微服務架構漫談架構微服務
- 架構演進之「微服務架構」架構微服務
- 解決方案架構、系統架構和企業架構區別架構
- 架構C01: 什麼是架構?為什麼做架構?架構師需要做什麼?架構
- 軟體架構模式之微服務架構架構模式微服務
- 架構設計之架構的演變架構
- 軟體架構風格——規則架構架構
- 架構設計之一——基礎架構架構
- 架構師眼中的高併發架構架構
- Spring Cloud雲架構-Restful 基礎架構SpringCloud架構REST
- Rust 中"上下文"設計構想 - Tyler MandryRust
- 看阿里P9架構師如何向你定義架構及架構師阿里架構
- ARM架構架構
- PostgreSQL 架構SQL架構
- Docker 架構Docker架構
- openGauss 架構架構
- presto 架構REST架構
- mvc架構MVC架構
- FreeSWITCH架構架構
- RocketMQ架構MQ架構
- iOS 架構iOS架構