敏捷架构

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：“我们重视个人和对流程和工具的交流。”

将敏捷“过程”定义为与代码库体系结构分开的抽象，违反了第一个原则的精神。