敏捷架構

Question

我開始我的研究生論文，主題將是「敏捷架構」

基本上，它會與傳統的軟件開發methologies的描述，和敏捷方法的後續誕生開始，提出建議整理和一個靈活的應用程序架構的設計很容易適應軟件構造的固有變化。

我的問題是，你會推薦什麼樣的模式和設計實踐這樣的架構？ 我對允許像類依賴注入，高可維護性和對特定問題的最大抽象等類解耦最大化的模式感興趣。

Answer 1

我提出以下建議：

1. 庫模式
2. 規格模式
3. 依賴注入
4. 領域驅動設計

基本上一切ALT.NET人羣言行一致。

Answer 2

當然，IoC的做法和基於合同的編程一般會在我的列表的頂部。然而，從經驗的角度來看，我只是爲了抽象而提出反對過分抽象的提法。例如。抽象因爲你可以而不是因爲任何人都能夠利用這種抽象。我已經看到那種架構變壞了，並且簡單地增加了系統的複雜度，使系統的維護變得更糟。

某種形式的反饋環繞着你的開發過程 - 無論是單元測試，持續集成和/或「scrum」會議。我意識到這並不屬於敏捷「架構」的範疇，但如果您沒有敏捷流程，那麼沒有任何「敏捷導向」架構的重要性。

Answer 3

這是一個有趣的問題。一個體繫結構可以獨立創建嗎？如果我們正在看XP這樣的東西，那麼我有點懷疑。或者，也許我誤解了，但這從來沒有阻止我擴大...

在XP中，要採取我更瞭解的方法，我們將在很短的時間內有一種結構開始一個項目;事實上，第一個故事完成的時間。在最初的故事寫作中，我們已經開始瞭解我們可能構建的內容 - 這是不可避免的：程序員傾向於用代碼來思考。但想得太遠，我們需要進入YAGNI領土。

我認爲，在敏捷環境中開發的應用程序的體系結構預計將通過特別是持續和專門的重構來消除重複而出現。

因此，或許問題是儘可能多的，以評估是否有特定的特性 - 或特性的類 - 即架構演進作爲敏捷處理的結果將趨於顯示。然後我認爲這將取決於我們正在構建什麼樣的應用程序，儘管已經提到的一些原則（我甚至可以理解其中的幾個原理）必須是可能的。

Answer 4

就我而言，敏捷不會傳播任何「架構」。敏捷是一種基於影響項目管理，發佈週期和一般開發實踐的基本原則的方法論，但肯定不是軟件架構。

這裏列出的所有軟件模式都可以使用強大的瀑布過程，這是敏捷開發的難題。

Answer 5

Onion Architecture

example

Answer 6

是，你擁抱變化的敏捷方式，即採用在需求和設計決策能改變的，接受重構等很多事情「傳統」的方式將在皺眉，因爲你是觸摸正在工作/以前同意的事物。

像XP這樣的方法試圖通過編寫單元測試來保持高質量。假設我們都同意編寫單元測試。

現在，您可以在這裏介紹一些體系結構，以便系統可測試或者測試友好，因爲並非所有系統都是可測試的。例如，使中間層可調用，並將業務邏輯與UI層分開。

Answer 7

我建議的基本設計實踐是首先構建您的架構的功能性，端到端 骨架。通過真實的反饋儘早驗證它。

這就是語用程序員所稱的「示蹤子彈」，Alistair Cockburn所指的「walking skeleton」。

您還可以在論文的背景下定義什麼應用程序在 ？你只考慮application software或 你還處理更復雜的系統？

Answer 8

如果羅伯特馬丁有任何關於它的說法（他稱之爲敏捷宣言的原始會議IIRC），那麼絕對的架構對於敏捷性來說絕對是一切。他的書Agile Software Development, Principles, Patterns, and Practices的整個第一部分是關於SOLID架構原則。這在某些方面有些爭議，但我不明白爲什麼。如果您的代碼庫非常脆弱並且耦合度很高，那麼它就不會變得非常開放，這是敏捷性的標誌。從概念上將代碼從代碼實踐中分離出來是一件非常敏捷的事情。

宣言原則1：「我們重視個人和對流程和工具的交流。」

將敏捷「過程」定義爲與代碼庫體系結構分開的抽象，違反了第一個原則的精神。