敏捷架构[关闭]

Question

我正在开始我的研究生论文，主题是“敏捷架构”

基本上，它将首先描述传统的软件开发方法，以及随后敏捷方法的诞生，最后提出建议和灵活的应用程序架构的设计，以轻松适应软件构建中的固有变化。

我的问题是，您会为这样的架构推荐哪些模式和设计实践？我对允许最大化类解耦的模式感兴趣，例如依赖注入、高可维护性以及对特定问题的最大抽象。

Answer 1

我推荐以下内容：

1. 存储库模式
2. 规格型号
3. 依赖注入
4. 领域驱动设计

基本上 ALT.NET 人群所宣扬的一切。

Answer 2

绝对是国际奥委会实践和 基于合同的 一般来说，编程将是我的首要任务。不过，根据经验，我会警告不要仅仅为了抽象而对问题进行过多抽象。例如。抽象是因为你可以，而不是因为任何人都能够使用这种抽象。我见过这种架构变得很糟糕，并且只是给系统增加了过高的复杂性，从而使系统的维护变得更糟。

围绕您的开发过程的某种反馈循环——无论是单元测试、持续集成和/或“scrum”会议。我意识到这并不真正属于敏捷“架构”的范围，但如果你没有敏捷流程，那么“面向敏捷”的架构就无关紧要。

Answer 3

我建议的一个重要的设计实践是首先建立一个功能性的端到端骨架。通过真实反馈尽早验证它。

这就是 Pragmatic Programmers 所说的“曳光弹”，Alistair Cockburn 所说的“行走的骷髅".

您还可以定义论文背景下的应用程序吗？你只考虑 应用程序软件 还是您还处理更复杂的系统？

Answer 4

这是一个有趣的问题，这个。可以孤立地敏捷地创建架构吗？如果我们正在研究像 XP 这样的东西，那么我有点怀疑。也许我误解了，但这从未阻止我扩展......

在 XP 中，采用我更了解的方法，我们将在启动项目后很短的时间内拥有某种结构；事实上，大约是第一个故事完成的时间。在最初的故事写作过程中，我们将开始了解我们可能构建的内容 - 这是不可避免的：程序员倾向于根据代码来思考。但想得太远会让我们陷入 亚格尼 领土。

我认为，在敏捷环境中开发的应用程序的大部分架构预计将通过持续和专门的重构来出现，以消除重复。

因此，也许问题在于评估是否存在特定的特征（或特征类别），这些特征是由于敏捷过程而演变的架构往往会表现出来的。然后我认为这将取决于我们正在构建什么样的应用程序，尽管已经提到的一些原则（其中一些我什至理解）肯定是可能的。

Answer 5

就我而言，敏捷并没有宣扬任何“架构”本身。敏捷是一种基于影响项目管理、发布周期和一般开发实践但肯定不影响软件架构的基本原则的方法。

这里列出的所有软件模式都可以通过强大的瀑布流程来使用，这对敏捷开发来说是令人厌恶的。

Answer 6

洋葱架构

例子

Answer 7

敏捷意味着你拥抱变化，即适应需求和设计决策的变化并接受重构等。许多“传统”方式会让人皱眉，因为你正在接触一些正在工作/之前同意的东西。

在像 XP 这样的方法中，尝试通过编写单元测试来保持高质量。让我们假设我们都同意编写单元测试。

现在您可以在这里引入一些体系结构，以便系统是可测试的或测试友好的，因为并非所有系统都是可测试的。例如，使中间层可调用、将 UI 层与业务逻辑分离等。

Answer 8

如果 Robert Martin 对此有什么要说的（他将最初的敏捷宣言称为 IIRC），那么架构绝对与敏捷息息相关。他的书的整个第一部分 敏捷软件开发、原则、模式和实践 是关于 坚硬的 架构原则。这在某些方面引起了一些争议，但我不明白为什么。如果您的代码库脆弱且耦合度高，那么它就不能非常开放地进行更改，而这正是敏捷性的标志。从概念上讲，将流程与代码实践分开是一件非常不敏捷的事情。

宣言原则1：“我们重视个人和互动，而不是流程和工具。”

对我来说，将敏捷“流程”定义为与代码库架构分离的抽象概念违反了第一条原则的精神。