如何在敏捷环境中完成建筑设计？

我已阅读《敏捷架构师原则》，其中定义了以下原则：

原则1：对系统进行编码的团队设计系统。
原则2构建最简单的可行架构。
原则＃3如有疑问，请将其编码。
原则4：他们构建，测试。
原则5：系统越大，跑道越长。
原则6系统架构是角色协作。
原则7：创新没有垄断。

该论文说，大多数架构设计是在编码阶段完成的，而在此之前只有系统设计。那也行。

那么，系统设计如何完成？使用UML？还是定义接口和主要块的文档？也许还有别的吗？

免责声明：我是敏捷环境中的建筑师，但正如长老赫尔姆特·冯·莫尔特克所说：“没有任何作战计划能够幸免于敌。” 换句话说，实用性意味着指南的确切含义不能总是得到遵守。

上面提到的大多数观点都是团队所能做到的。但是，当团队由数十个（或数百个）跨不同洲和时区的开发人员组成时，原则1（由系统编写代码的团队设计系统）确实很难遵循。这与开发人员的技能或态度无关，更多的是他们存在的后勤问题，这些问题都是为了收集客户的需求并了解现有的复杂系统。

那么，系统设计如何完成？使用UML？还是定义接口和主要块的文档？也许还有别的吗？

架构师通常会确定主要组件，然后定义它们之间的接口（包括非功能性要求，如安全性，速度和可靠性），并将组件的内部设计委托给各个团队。在让团队设计自己的组件而不要求每个人都了解有关系统的所有知识之间，这是一个很好的折衷方案。

每个组织都有自己的一套体系结构设计标准，有时在组织内的各个项目之间会有所不同。该设计是在团队开始编码之前或尽可能早地完成的，通常包含（并且不是完整列表）：

1. 扩展了需求和范围定义。这些包括充实了更高级别业务需求的用例或用户案例。我个人喜欢将RFC 2119用于非功能性要求。设计基于并追溯到这些。尽管它可能不符合设计的通用定义，但它们通常同样重要。
2. 概述，包括高层网络或组件图和一段文本。从高层管理人员到开发人员和质量检查人员，这是一个非常广泛的受众。由于受众广泛，因此很少使用UML或定义的符号。
3. 各个组件的详细信息，通常着眼于如上所述的它们之间的接口或API。可以将接口指定为目标语言中带有前置条件和后置条件详细信息的方法签名。组件可能具有网络图，例如显示云或数据中心中VM的布局及其网络布置。关系数据库通常将具有实体关系图。
4. 已知的体系结构风险及其缓解措施列表。像需求一样，这些证明了设计决策和权衡取舍。

简而言之，敏捷过程中的系统设计与传统瀑布过程中的系统完全相同。但是，在敏捷环境中，较少的设计是预先完成的，而更多的设计则委托给组件团队。关键是确定最初要走的深度，要推迟的决策以及确定何时需要做出决策。影响多个开发团队的决策应及早做出，尤其是可伸缩性和安全性。诸如将其他语言添加到已经国际化的产品中的决定可以推迟到很晚。

创建初始设计后，架构师与每个团队合作并审查他们的设计。如果某个工作单元（例如Scrum冲刺）需要进行其他设计或设计更改，则架构师的目标是在该工作单元开始时就可以使用它。架构师还负责将任何更改传达给受影响的团队或利益相关者。

免责声明：我不是敏捷教练/架构师-这是我在从事的敏捷项目中所看到的，并且我认为它运作良好。

我不认为敏捷如何定义架构是非常明确的-敏捷专注于开发方法和实践。另一方面，UML只是一种交流您的体系结构的语言，它超出了敏捷性（如果适合您的项目和团队，则可以使用它）。

真正适用的体系结构原则之一是在可能的负责任时刻做出决定-这意味着如果您在项目开始时没有做出所有决定，那很好，尤其是因为在此阶段您掌握的信息最少。随着时间的流逝，您可能会做出“演变”架构的决定。是的，这可能看起来有些返工，但这也是由于您已经了解了有关环境，需求，什么是可能的，什么是不可能的等新知识。

您要避免的主要事情是体系结构腐烂-代码实际上并不符合任何特定的体系结构，而只是一团糟。与不断发展的体系结构相比，主要区别在于，在体系结构中，您需要定期做出明智的决策并以明确的理由记录下来，然后继续进行以确保您的代码遵循该决策。

在进行测试驱动的开发时，您将创建测试代码以隔离地测试模块（=尽可能独立于其他模块）

为了简化测试代码的创建，您将接口引入其他可以轻松模拟的模块。

这种附带影响会自动使您获得一种架构，其中模块之间的耦合尽可能小。

我认为tdd也是建筑作品。