連續架構六大原則 - Murat Erder

連續架構六大原則

• 連續架構不是一種架構方法。這真的是一種心態，幾乎是一種工作方式，一種思維方式。
  
  1. 第一個是你應該架構你的產品。很多人會考慮我需要實施的專案，但您應該考慮我正在實施的軟體產品是什麼，以及它的旅程是什麼。
  2. 第二個是“關注質量屬性而不是功能需求”。我們需要系統的非功能性需求：安全性、可擴充套件性、彈性、效能等。因為這些是真正測試您的系統或架構的關鍵因素。我們有時只在遇到大問題時才會處理它們。
  3. 第三個原則是“延遲設計決策，直到它們絕對必要”。
  4. 架構的核心單元是設計決策，您必須在正確的時間做出決策。這是我們從敏捷世界中汲取的原則。
  5. 你不能預先做一個大的設計。您必須儘早發展並做出關鍵決定，但將某些決定推遲到以後。因為如果你不這樣做，那麼你最終會過度設計你的系統。
• 原則四是“架構變革，利用小力量”。這就是鬆散耦合的內部相干元件。想想你的架構會在哪裡改變，有鬆散耦合的獨立元件。
• 原則五是“構建、測試、部署和操作的架構師”。在構建系統時，不要只考慮已實現的架構，還要考慮如何構建它、如何測試它、如何部署它以及如何操作它。
• 原則六是承認康威定律，即“系統設計後團隊的模範組織”。這有兩個方面。
  
  • 一個是敏捷世界，我們真正相信跨職能團隊。不要有獨立於應用程式開發團隊和測試團隊的獨立資料庫團隊。我們想避免那些內部連貫的事情。
  • 對此的更宏觀解釋是承認您在組織中的地位以及您擁有哪些組織結構。因為康威定律說，每個軟體系統或每個系統都將反映構建它的組織的通訊結構。

資料模型的重要性
這是關鍵。有兩個方面。

• 一是共同通用語言。還有領域驅動設計中無處不在的通用語言。
  
  • 當你說話時，我們必須有共同的語言。不僅是開發軟體的團隊，還有與業務利益相關者的通用語言。這很重要，因為如果您不會說一種通用語言，就很難理解您正在解決什麼問題。
  • 如果你不定義它——它不必是一個詳細的模式或 DDL，它實際上只是有一種共同的語言可以與之交談，你最終會在迴圈對話中——你可能會實現不符合業務需求。擁有一個軟體產品的通用語言，實際上是跨越你支援企業的軟體產品，是非常重要的。
• 第二個方面是針對每個資料實體，瞭解哪個應用程式在掌握它，哪個應用程式正在使用它。
  
  • 同樣，這是一件非常簡單的事情，但是如果您不預先考慮它，您最終可能會在多個應用程式之間出現非常令人困惑的資料整合點以及我們所謂的資料菊花鏈。
    
    • 您從另一個應用程式獲取資料，稍微修改它，然後將其傳送到第三個應用程式。他們修改了它，然後將其傳送給第四個。在您知道之前，沒有人真正考慮過誰擁有哪些屬性或哪些識別符號，結果一團糟，因為您開始檢視它們，實際上您的業務表現不一致。

資料技術趨勢

• 我在金融服務和製藥領域看到的一個趨勢可能更多，它不是技術趨勢，而是專注於資料治理。正確定義資料並確保業務利益相關者擁有該資料的所有權。
• 如果你仔細想想，有兩種型別的系統。有更多的作業系統和更多的資料分析系統。我認為帶有微服務的作業系統以及我們討論過的事情；我們知道如何更好地構建它們。
• 但是當你看到一家公司時，就會出現這種大分裂，然後你的資料分析世界曾經是大資料倉儲，一些專有的像 Teradata 之類的東西，然後我們進入了 Hadoop 世界，每個人構建資料湖，您可能會應用新技術，但這仍然是一個整體。
• 一個大趨勢是來自 ThoughtWorks 團隊的資料網格概念。這非常強大，因為它涉及應用與為資料架構構建作業系統相同的概念。它應用了我們的一些核心原則，因為您開始將這些資料視為一種產品。也講了很多原則六，就是團隊的組織。
  
  • 這些大的傳統資料分析基礎設施的挑戰在於，您擁有各種專家，而這些專家是集中的，他們必須管理一切，而且他們沒有足夠的領域知識，因為技術是如此專業。這些專家專注於這一點。
  • 因此，當您嘗試實施此資料網格概念時，即以某種方式圍繞資料產品建立元件時，您還希望確保這些團隊具有技術知識，或能夠訪問該技術知識以支援他們的資料產品。
• 最終的一致性很有趣，它已經存在了很長一段時間。事實上，如果你仔細想想，我們的現實生活最終是一致的。同樣，這是您正在構建的應用程式型別。
• 你必須思考什麼是對的。擁有一個符合 ACID 的資料庫有一個非常強大的地方，您相信它可以為您管理應用程式的狀態。這是一個非常強大的工具。因為一旦你離開那一刻，你就必須自己做更多的工程。你不得不說，由於我正在構建的軟體產品的性質和我想要的質量屬性的性質，我進入了一個更加分散、最終一致的世界，這是值得的。

資料作為架構關注點

• 資料是一個有趣的話題。我們經常使用它。幾乎失去了意義。我們所說的資料是什麼意思，您如何將其視覺化？
• 我們擁有的資料將永遠比系統更長壽。因此，資料是我們運營方式的核心。
• 過去 10 年發生的一個重大變化是引入了新的資料庫技術。20-25 年前，如果您構建了一個系統，那麼您將擁有一個關聯式資料庫幾乎是毫無疑問的。最大的爭論是我是使用 Oracle 還是 Sybase，還是 SQL，不管它是什麼。
• 現在，主要是由於處理大規模網際網路問題的大型科技公司，那裡有很多新的，不僅僅是 SQL 解決方案。它們解決了許多優秀的技術方面，但與過去相比，您的資料已更多地整合到您的架構中。如果您使用鍵值儲存、文件儲存或圖形儲存，它確實會影響您對應用程式及其執行方式的看法。它真正涉及我們預先設定的質量屬性。
• 這些是更難改變的事情。你可以拆分你的元件，你可以做很多事情，你可以重構你的程式碼很多。但是改變你處理的底層資料結構和你做出的一些決定是基本的。它們比過去更具侵入性。

基本活動
基本活動解決了一個問題：什麼是持續架構？做好架構是什麼意思？必不可少的活動，如果你什麼都不做，你必須做這四件事。您可以根據需要繪製任意數量的圖表，也可以繪製任意數量的圖表。你可以像這樣、那樣地組建你的團隊。但這是要說的四件事，“我在做一個架構。”

• 有這四個元件，它們是架構決策、技術債務、質量屬性和反饋迴圈。
  
  • 主要的是架構決策。這是您作為架構師的核心工作單元。你知道你正在做的決定和你沒有做的決定以及它們的影響。
  • 第二件事是你必須瞭解你的技術債務。我在當前平臺上的技術債務是什麼？當我做出決定時，我是在減少還是增加技術債務。因為這是您對產品可持續性的長期看法。
  • 第三件事是質量屬性。您必須關注質量屬性。您必須確保從可擴充套件性、彈性等方面瞭解您的需求，並且您必須圍繞這些事情構建測試工具，並瞭解您滿足它們的程度。
  • 最後，它實現了反饋迴圈。這是最重要的事情。你建立團隊的方式和你的發展方式，你應該儘快獲得所有這些方面的反饋迴圈。