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

基本上，它将首先描述传统的软件开发方法，然后是敏捷方法的诞生，最后给出建议以及易于适应软件构造固有变化的灵活应用程序体系结构的设计。

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

解决方案

回答

我建议以下内容：

• 储存库模式
• 规格模式
• 依赖注入
• 域驱动设计

基本上，ALT.NET人群会讲的所有东西。

回答

绝对可以肯定的是，IoC实践和基于合同的编程通常是我的榜首。不过，从经验来看，我会告诫不要仅仅为了抽象而将过多的问题从问题中抽象出来。例如。之所以要进行抽象，是因为我们可以这样做，而不是因为任何人都将能够使用该抽象。我已经看到这种体系结构变坏了，只是简单地给系统增加了一定程度的复杂性，从而使系统的维护变得更糟。

围绕开发过程的某种反馈循环-单元测试，持续集成和/或者"混乱"会议。我意识到这并没有真正落入敏捷"架构"的范围，但是，如果我们没有敏捷流程，那么"以敏捷为导向"的架构就不会有任何意义。

回答

这是一个有趣的问题。可以隔离创建敏捷架构吗？如果我们正在寻找类似XP的产品，那我会有点怀疑。也许我误会了，但这并没有阻止我扩展……

在XP中，要采用一种我更了解的方法，在开始一个项目后的很短时间内，我们将具有某种结构。实际上，关于第一个故事的完成时间。在最初的故事编写过程中，我们将开始逐渐意识到不可避免的构建方式：程序员倾向于以代码的方式进行思考。但是，如果想得太远，我们就会进入YAGNI领域。

我认为，在敏捷环境中开发的应用程序的许多体系结构都有望通过特别是不断重复的专用重构来消除重复出现。

因此，也许有很多问题可以用来评估是否存在由于敏捷过程而导致的架构演化出的特定特征或者特征类别。然后，我认为这将取决于我们正在构建哪种类型的应用程序，尽管可能已经提到了某些原则(我什至理解了其中的一些原则)。

回答

就我而言，敏捷并没有像这样宣扬任何"架构"。敏捷是一种基于影响项目管理，发布周期和一般开发实践的基本原理的方法，但当然不是软件体系结构。

此处列出的所有软件模式都可以通过强大的瀑布式流程来使用，这对于敏捷开发而言是一种厌恶。

回答

洋葱架构

例子

回答

敏捷意味着我们要接受变更，即采用变更需求和设计决策并接受重构等方法。许多"传统"方式都将被驳斥，因为我们接触的是正在工作的/先前同意的东西。

在XP之类的方法中，试图通过编写单元测试来保持高质量。假设我们都同意编写单元测试。

现在，我们可以在此处介绍一些体系结构，以便系统可测试或者易于测试，因为并非所有系统都可测试。例如，使中间层可调用并将UI层与业务逻辑分开等。

回答

我建议的一种基本设计实践是首先构建功能齐全的端到端
架构的骨架。尽快通过真实的反馈进行验证。

这就是实用程序员所说的"追赶者子弹"，而阿利斯泰尔·考克本则叫"步行骨架"。

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

回答

如果罗伯特·马丁(Robert Martin)对此有话要说(他称其为最初的与IIRC会面的敏捷宣言)，那么绝对与敏捷有关的一切都与建筑有关。他的《敏捷软件开发，原理，模式和实践》一书的整个第一部分都是关于SOLID体系结构原理的。在某些方面这一直存在争议，但是我不明白为什么。如果代码库是脆弱的并且耦合程度很高，那么它就不能很开放地进行更改，这就是敏捷性的标志。从概念上将过程与代码实践分开是一件非常不灵活的事情。

宣言的原则1："我们重视个人以及流程和工具之间的互动。"

在我看来，将敏捷"流程"定义为与代码库体系结构不同的抽象概念违反了第一条原则的精神。