敏捷架构

Question

我正在开始我的毕业论文，主题将是“敏捷架构”

基本上，它将首先介绍传统的软件开发方法，随后出现敏捷方法，完成建议和灵活的应用程序架构设计，以便轻松适应软件构建的固有变化。

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

Answer 1

我建议如下：

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

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

Answer 2

一般来说，IoC实践和基于合同的编程绝对是我的首选。但是，从经验来看，我会提醒我不要仅仅为了抽象而过分抽象。例如。抽象，因为你可以而不是因为任何人都能够利用这种抽象。我已经看到这种架构变坏了，只是给系统增加了太高的复杂程度，使系统维护变得更糟。

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

Answer 3

我建议的一个基本设计实践是首先构建一个功能性的端到端 你的建筑的骨架。通过真实的反馈尽早验证它。

这是实用程序员称之为“Tracer Bullets”，而Alistair Cockburn称之为“walking skeleton”。

您还可以定义应用程序的内容 你论文的背景？你只考虑application software或 你还处理更复杂的系统吗？

Answer 4

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

在XP中，采取我更了解的方法，我们将在开始一个项目后的很短时间内建立某种结构;事实上，关于第一个故事完成的时间。在最初的故事写作过程中，我们已经开始了解我们可能构建的内容 - 这是不可避免的：程序员倾向于考虑代码。但是，思考太远将我们带入YAGNI领域。

我认为，在敏捷环境中开发的应用程序的大部分体系结构都应该通过特别是不断重复的专用重构来实现。

因此，或许问题在于评估是否存在特定特征 - 或特征类 - 由于敏捷过程而倾向于显示架构的演变。然后我认为它将取决于我们正在构建的应用程序类型，尽管已经提到的一些原则（我甚至理解的其中一些原则）必须是可能的。

Answer 5

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

此处列出的所有软件模式都可以使用强大的瀑布流程，这是敏捷开发的诅咒。

Answer 6

Onion Architecture

example

Answer 7

敏捷意味着你接受改变，即采用改变要求和设计决策并接受重构等等。许多“传统”方式会不屑一顾，因为你正在接触那些有效/先前同意的东西。

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

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

Answer 8

如果罗伯特·马丁有任何可以说的话（他称之为最初的敏捷宣言会议IIRC），那么绝对的架构与敏捷有着一切。他的书Agile Software Development, Principles, Patterns, and Practices的整个第一部分是关于SOLID建筑原则。这在某些方面引起了一些争议，但我不明白为什么。如果你的代码库很脆弱并且耦合很多，那么改变它就不会很开放，这是敏捷性的标志。从概念上将过程与代码实践分离是一件非常敏捷的事情。

宣言的原则1：“我们重视个人和对流程和工具的互动。”

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