7.建模你的架构

架构建模的主要目标应该是就您打算如何构建系统达成共识或理解。换句话说，你将建模以理解。我的经验是，99.999％的软件项目团队需要花一些时间来建模他们系统的架构，即使是依赖于隐喻来指导他们的开发工作的Scrum / XP团队也是如此。虽然你的XP团队正在识别你的系统的比喻，你和你的队友在开发你的初始版本时会想到好几周，但你经常会画出你认为你的系统如何工作的草图。在AM的练习放弃临时模型之后，您可能不会保留这些草图，这通常是因为它们是无法解决的想法，或者仅仅是因为您正在建模以了解问题，所以一旦您这样做，图表就不再对您有价值了。话虽如此，XP团队开发架构模型并没有错。这些模型可能就像你在公众可见的白板上留下的草图一样简单，因为虽然隐喻可以是非常有效的东西，但架构模型通常会提供团队所需的更多细节。正如您所期望的，Disciplined Agile Delivery（DAD）团队也将进行一些架构建模。

您如何以敏捷的方式为您的架构建模？我通常会努力创建一个或多个导航图，图表显示系统“景观”的概述。就像路线图概述了城镇的组织一样，您的导航图概述了系统的组织结构。导航图是系统架构视图的实例。当您阅读有关架构建模的书籍和论文时，作者提出的一个共同主题是需要各种架构观点，每位作者都会展示他或她自己的关键视图集合，您需要考虑这些观点。我的经验是，没有一套架构视图适合每个项目，而项目的性质将有助于定义您应该考虑创建的视图类型。这意味着您创建的导航图类型取决于您正在构建的系统的性质。这在概念上与AM的实践一致应用正确的工件，它告诉您应该使用正确的建模技术来完成手头的任务。例如，使用基于J2EE的技术构建复杂业务应用程序的团队可能会发现UML组件图和工作流图适合用作体系结构导航图。但是，构建企业数据仓库的团队可能倾向于使用基于其体系结构的数据模型和UML部署图。不同的项目，不同的架构视图，因此不同类型的导航图。有趣的是，两个项目都需要两个导航图，符合多模型原则。您需要灵活处理您的方法，因为一种尺寸并不适合所有情况。

组织将犯的一个常见错误是将其架构工作建立在其组织结构上。例如，具有强大数据组的组织可能希望将数据模型作为其体系结构的主要工件，而不管系统的实际性质如何。当你有锤子专家时，每个问题看起来都像钉子一样。当您使用新技术或尝试开发组织几乎没有经验的新系统时，这个问题非常普遍 - 过去运行良好的组织结构在您的新环境中可能不再适合您。有关架构和组织结构的含义的更多信息，请参阅Conway定律的组织模式。

要创建导航图，建模工作的主要驱动力应该是假设简单。创建简单内容的做法表明您应该努力识别可能的最简单的体系结构方法 - 您的体系结构越复杂，个体开发人员不会理解它的可能性就越大，错误和崩溃的机会就越大。此外，您的架构模型应包含正确级别的信息，显示系统的各个方面如何协同工作，而不是细节（这就是设计的全部内容）遵循实践描述模型简单。您还应该使用最简单的工具来完成这项工作，很多时候，您需要使用白板草图来模拟架构的关键方面。绘图工具可以使用CASE工具。普通旧白板（POW）可以使用绘图工具。当纸张和便利贴可以使用时，请勿使用POW。

重要的一点是，当您的所有通信都是面对面的时，导航图通常足以描述您的架构。如果不是这种情况，当您的架构所有者无法与开发人员密切合作时（可能某些开发人员位于远程位置），那么您需要使用文档补充图表。

当您进行架构建模时，您应该考虑利用可用的丰富架构模式，但您应该以有效的方式进行。“模式系统：面向模式的软件体系结构”这本书是开始学习常见体系结构模式的好地方，例如图层，管道和过滤器，代理，模型 - 视图 - 控制器和Blackboard。与分析和设计模式一样，应该按照惯例轻轻地应用模式 - 只有在明确需要时才将它们引入您的架构中。在此之前，如果您怀疑架构模式可能是合适的，那么您可能认为您将拥有需要代理的多个关键服务来源，然后对您的架构进行建模，以便在实际情况出现时应用此模式。请记住，您正在逐步开发系统，遵循小增量中的练习模型，并且您不需要在第一天就建立正确的体系结构（即使您愿意，也无法实现此目标）。

您应该认识到，您的架构模型将揭示您的系统对其他系统的依赖性或它们对您的依赖性。例如，您的系统可以通过Internet与信用卡处理服务交互，从遗留关系数据库访问数据，或为另一个内部应用程序生成XML数据结构。网络图和UML部署图对于识别这些依赖性非常有用，面向过程的模型（如工作流程图，UML活动图和数据流图）也非常有用。这意味着这些依赖关系表明可能需要遵循这样的做法：在您的团队与您共享依赖关系的系统的所有者之间正式化合同模型。理想情况下，许多这些模型已经到位，信用卡处理器可能具有您必须遵循的严格定义的协议，并且遗留数据库可能具有为其定义的物理数据模型，尽管诸如XML数据结构之类的新功能将需要足够的定义。有时，如果没有准确的文档，您需要对旧系统的现有接口进行分析，有时需要设计新的接口。在这两种情况下，都需要由您的团队，其他团队或合适的联合开发相应的合同模型。

您应该如何组织架构建模工作？在项目开始时，我将典型地将架构团队聚集在一个单独的房间中进行初步构想。理想情况下，这个会议将持续不超过几个小时，但在一些较大的项目上，它可能持续几天甚至几周（我会认真地质疑任何超过两周的努力）。与往常一样，建模会话越长，由于缺乏反馈而偏离航线的可能性就越大。这个建模会议的目标是就我们正在建立的系统的格局达成初步协议，或许不是达成共识，而是足够的协议，因此我们可以开始作为一个团队向前迈进。

8.考虑几种替代方案

正如精益软件开发告诉我们的那样，我们不应该尽早采取架构策略，而应该考虑几种替代方案，并且只要它们仍然可行，就让这些替代方案对我们“开放”。这意味着，当您在项目早期构想架构时，您应该真正设想出几种可能的架构。公平地说，这种策略并不是新的，事实上，这种策略已经在IT架构社区中推广了几十年，尽管并不总是如此。

9.记住企业约束

除最新组织外，所有组织都拥有现有的技术基础设施。更成熟的组织可能有：

• 他们正在努力实现的技术基础设施的“前景”愿景
  
• 企业级标准和指南 - 用于开发，数据，用户界面，安全性等 - 项目团队应遵循的标准和指南
  
• 用于降低总体开发和运营成本的战略性重用策略
  
• 企业架构，战略重用和/或类似的团队，负责发展和推广这些事物
  
• 运营和支持组织，有时也称为系统管理组织，负责在生产中运行组织的系统
  

关键是这些企业级考虑因素为开发团队提供了挑战和机遇。虽然每次构建一个新系统时从一个干净的架构板开始会很棒，但实际情况是在绝大多数情况下策略都是不合适的。多年来我见过几个敏捷项目团队因为他们选择重新开始，声称他们的架构随着时间的推移而出现，他们有勇气担心明天明天的问题，他们制作了潜在的可交付软件。定期，并基本上嘲弄任何其他敏捷的言论，他们认为这些言论证明了他们的愚弄。训练有素的团队构建系统，其架构出现在他们工作的组织环境中。他们谦虚地认识到他们无法做出他们想要的所有技术决策，而是受到现有基础设施和愿景的限制。此外，他们还生产可在组织生态系统中使用的可消耗解决方案。

幸运的是，企业关注的焦点也很多。通过利用现有的基础架构团队，可以更快地提供，因为他们的构建更少。通过使用现有技术，或者至少通过使用企业愿景中提到的新技术（对您的组织来说是新的），他们通过帮助最小化运营成本来降低系统的总体拥有成本（TCO）。通过遵循公司发展准则，它们有助于提高工作的一致性和质量，增加其可维护性，以便将来负责发展和维护工作。顺便说一句，软件开发上下文框架（SDCF）的企业规程扩展因子是八个中唯一的扩展因子，这使得开发团队可能更容易实现，因为这个因素远离项目级别的重点（ “容易”的情况）到企业层面的焦点（“硬”情况）。

那你怎么做的？最低限度，企业架构师，运营团队等企业集团是重要的利益相关者，应由您的产品所有者代表。对于您的企业体系结构组，其中一个或多个可能成为您的开发团队的活跃成员，具有架构所有者的角色。对于其他组，产品所有者可以根据需要和适当的即兴基础选择让他们作为域或技术专家参与您的团队。

10.轻装上阵

您的架构工作的一个目标应该是轻装上阵，尽可能灵活。当一个五页的文档可以做时，不要创建一个五十页的文档。当图表执行时，不要创建一个五页的文档。当隐喻可以做时，不要创建图表。记住“他们不会读它（TAGRI）”的原则。

不确定如何创建文档？错误的是因为你可以随时回到白板，但是你浪费了创建你不需要的工件或者为工件添加不必要的细节的时间已经一去不复返了。您的目标应该是考虑项目团队（或组织甚至行业所面临的关键问题，具体取决于您的范围），不应该创建大量的文档。最大化股东投资回报率的原则告诉您要专注于高价值的活动，例如作为一个团队解决困难问题并达成共同愿景。同样，它告诉您要避免低价值的活动，例如撰写详细的文档或开发分数漂亮的图表。这些活动往往令人感到欣慰，因为它们提供了进步的幻觉，如果你试图避免处理棘手的问题，就会为你提供一个离题的来源，但实际上很少像你想象的那样有效，因为其他人很少看到比作者。原则软件是您的主要目标意味着您应该对您的架构进行建模，直到您认为自己有可行的策略为止，此时您应该继续开始开发软件而不是文档。

您何时想撰写架构文档？在我看来，有两个例子让它变得“敏捷”。首先，当您拥有分布式开发团队并且无法找到更有效的沟通方式（例如面对面交谈）时，文档就是一种选择。其次，在项目结束时，您希望留下足够的文档，以便其他人可以在以后了解您的方法。现实情况是，对于相当复杂的系统来说，记录代码中的所有内容是非常困难的，如果不是不可能的，当然也不可取。有时，描述您的体系结构的最佳位置是简要的概述文档。本文档应侧重于解释您的架构的关键方面，可能由您的导航图捕获，它可能包括关键架构要求的摘要，以及对您所做的“可疑”方面背后的关键决策的解释。与往常一样，如果您要创建一个架构文档，那么它应该增加正值，理想情况下应该以最有效的方式执行。

很多人在发现架构没有“记录良好”时会感到担心，无论这意味着什么。我并不是很担心这个问题，但我担心的是架构是否真实，以及开发人员是否理解并接受它。如果您要优先考虑您的体系结构文档，拥有可行的体系结构，让开发人员理解该体系结构，并让所有开发人员都能使用它，那么我怀疑文档将在该列表中排在最后。想一想。

11.证明你的架构

实践证明它与代码指出模型只是一个抽象，一个看似非常好的模型在实践中可能实际上并非如此，你可以肯定知道的唯一方法是通过实现验证你的模型。这意味着你应该证明你的架构是有效的，XP称之为尖峰，RUP称为架构原型。当您的架构呼唤一些对您来说不熟悉的东西时，也许您是第一次使用两个或更多产品，您应该花时间来探索这种方法是否能够如何工作以及它是如何工作的原则快速反馈。记住要获得项目利益相关者的许可才能完成这项工作，因为这是他们花的钱。有时您会通过努力发现原始方法不起作用，我希望尽早发现，有时您会发现您的方法实际上是如何工作的（而不是您认为它的工作方式）。架构尖峰/原型的开发有助于降低项目风险，因为您可以快速发现您的方法是否可行，您还没有简单地制作象牙塔架构。

图5概述了优先需求“最佳实践”的敏捷方法。通过对交付生命周期的风险价值方法，Scrum价值驱动生命周期的扩展，您将确定解决项目主要技术风险的少数需求。例如，如果您的要求表明您的系统必须能够在10小时内每秒处理4,000个事务，那么这将是一个明确包含某些技术风险的要求。这是您希望在项目早期实现的一种要求，以确保您的体系结构真正起作用。我的一般规则是，当你进入为期6个月的项目仅18天而不是在“6个月项目”的8个月点结束时，最好发现你的架构策略需要重新考虑。这意味着，如果技术风险要求不在积压的首位，那么您需要与产品所有者密切合作，以说服他们重新确定优先级不高的要求。但是，如果您无法说服您的产品所有者这样做（我在实践中从未遇到过这个问题，但认识到可能会发生这种情况），那么您需要尊重他们的决定并接受以后证明您的架构的风险生命周期。

图5.工作积压。

12.传达您的架构

有两个主要受众，您的架构的沟通很重要：您的开发团队和项目利益相关者。为了促进您的开发团队之间的沟通，我坚信您应该遵循公开展示模型的所有架构图，因为一个严密保密的架构不是一个架构，它只是一个徒劳无益的自我锻炼。我参与了几个项目，我们成功地维护了一个专门用于架构图表的白板，让它们公开显示给项目中的每个开发人员以及偶然走过的任何其他人。我们还允许任何想要在图表中添加评论或建议的人，按照开放和诚实的沟通原则以及集体所有权的实践，因为我们希望他们对我们的工作有所反馈。我们没有什么可隐瞒和信任的，其他人愿意帮助我们（他们确实）。

在项目开始时，在整个项目中不那么频繁，您经常会发现需要使图表“看起来很漂亮”，这样您就可以将它们呈现给您的项目利益相关者。您的利益相关者希望了解什么是什么您打算采取的方法来确定您是否明智地投入资源，这意味着您需要建立模型来沟通和定位您的某些模型，以便其他人可以理解它们。这可能意味着您需要花时间来清理模型以使其可呈现以及为它们编写概述文档。为了保持尽可能灵活，有目的的模型原则告诉您，您应该确切地知道您正在为谁开发模型以及他们将使用它们，以便您可以专注于所需的最小努力。向重要的项目利益相关者进行演示，这些工作往往令开发人员烦恼和分散注意力，这对项目的成功至关重要，因为它们为您提供了获得项目支持和获取所需资源的机会。此外，您可以提升让您可以积极参与项目的利益相关者的重要性（如果您没有可用的利益相关者，则无法遵循主动利益相关方参与的做法）。

准备好在演示文稿中传达您的架构，没有理由不能保持演示文稿的敏捷性。

13.考虑未来，但不要过度建设（推迟承诺）

我怀疑关于敏捷架构建模的最具争议性的概念是你应该考虑未来的变化，但在你真正需要之前不要采取行动。换句话说，不要过度构建你的系统，但同时要聪明一点。XP社区对于过度构建软件的概念相当直率，他们相信“你无论如何都不需要它”（YAGNI）。基本思想是你无法准确预测未来[1]，因此不应该为未来的可能性而努力。相反，您今天应该专注于构建您现在需要的东西并干净地构建它，以便您的软件在需要时易于更改。明天，当您发现需要更改软件以满足新要求时，请更改它。当您过度构建软件以更加通用时，为了满足未来的潜在需求，您实际上正在做出非常严肃的权衡：

• 很难估计你正在生产的实际价值。您并不专注于满足当今的需求，导致您不会为您的用户带来直接的价值。我参与了几个项目，前几个月，在少数情况下，前几个季度，我们的工作重点是开发通用基础架构（持久性框架，消息传递框架等）。技术上有趣的东西，我们肯定有很多乐趣构建它们，但对我们的用户没有任何价值。
  
• 你在猜。你真的不知道你是否甚至需要你正在建造的任何东西 - 当一辆大众汽车足够时你可能正在建造一辆保时捷。
  
• 你增加了维护负担。您今天过度建造的任何东西都需要在项目的整个生命周期中进行测试和维护，这违反了Travel Light的原则。
  
• 目前尚不清楚它需要在多大程度上进行测试。当你过度建造某些东西时，唯一可以准确验证它的方法就是通过虚构的反馈 - 没有人要求你过度建造任何东西，所以没有人可以去验证你的工作。此外，大多数开发团队都会测试风险，但如果您猜测需求，那么您也会猜测风险级别。
  

所以你怎么能对这一切都很聪明？虽然您不希望根据未来/神话要求过度构建系统，但考虑未来并没有任何问题。这是一个两阶段战略：

• 初始建模。做一些初步的架构，设想思考问题，探索关键概念，从而让你朝着正确的方向前进。这并不意味着您需要创建大量的架构文档，尽管您可能会进行一些建模，是的，egads！，甚至可以创建足够的架构文档来满足您的需求。
  
• 推迟设计决策。精益软件开发的原则之一是推迟对您需要做出决定的最后可能时刻的承诺，从而提高您的灵活性并提高您的成功机会。
  

一个有趣的策略是变更案例建模。变更案例用于描述系统的新潜在要求或对现有要求的修改。变更案例是您未来可能需要或可能不需要支持的要求，但您今天绝对不需要支持。变更案例通常是与项目利益相关者进行头脑风暴的结果，其中诸如“业务如何变化？”等问题。“什么立法可以改变？” “你的竞争对手在做什么？”和“还有谁可能会使用该系统以及如何使用？”在技术方面，开发人员经常会提出诸如“什么技术可以改变？”等基本问题。和“我们需要与哪些系统进行交互？”这将导致识别变更案例。变更案例应该是现实的，例如“我们为银行进入保险业务”或“我们需要支持我们系统中的[INSERT FLASHY NEW TECHNOLOGY]”是合理的变更案例，但“我们的销售人员被不明飞行物绑架” “T。此外，变更案例通常描述的要求与您当前正在处理的要求相当不同，这些要求可能会导致重大的返工。通过识别变更案例，您现在可以智能地选择看起来与架构或设计决策相同的内容。当您的当前要求不足以帮助您在备选方案之间进行选择时，您应该只将相关的变更案例纳入决策过程。另一个优点是你现在可以向你的项目利益相关者解释为什么你选择一种方法而不是另一种方法，因为我想说你有一个故事要讲。但是，我不能强调改变案例不应该被用作为你的系统镀金的借口。保持敏捷，不要过度构建系统。那么当你认为你有一个你真正相信现在需要实施的变革案例时，你会怎么做？简单 - 与项目利益相关者讨论。询问他们是否立即要求变更案例，如果是，则相应地采取行动。如果这不是一个直接的要求，那么接受这个事实并继续前进。永远不要忘记项目利益相关者有责任确定需求的优先级，而不是您的需求。

未来的建模是否会受到损害？这是一个滑坡，因为我怀疑如果你建模它然后你更有可能建立它。我相信，这需要严格的纪律，不要过度建造，因为一旦你把它作为一系列气泡和线条捕获，就很容易让自己相信过度建造一次就没有坏处。已经说过，在讨论变更案例的时候绘制一些丢弃的草图并没有什么不妥，只是不要过度建模你打算保留的任何模型。

14.采用多视图方法

敏捷建模的多模型原则建议您认识到，因为现代系统很复杂，您需要考虑架构中的一系列视图。虽然它们采用不同的方法，但多视图策略是现代架构框架中的基本概念，例如Zachman框架，TOGAF，4 + 1等。这些框架中的每一个都有很好的理由来选择视图，它们在实践中似乎都运行良好，它们都可以灵活地进行处理，所以我的建议是检查您的选项并选择最能反映出来的架构框架。您组织的文化。我的目标不是提出另一个架构框架，而是让您了解它们及其基本概念。图6概述了软件/系统架构师需要关注的视图和关注点（通常称为服务质量要求）。

图6.架构视图和关注点。

视图/视点被捕获为图表和文本描述（例如用例，技术规范或散文）的组合。潜在的问题，可能是您自己的观点，您的架构应该解决的观点包括：

• 用法/业务流程
  
• 用户界面
  
• 系统界面
  
• 网络
  
• 部署
  
• 硬件
  
• 数据存储
  
• 数据传输
  
• 活动
  
• 代码/组件分发
  
• 功能/逻辑/服务
  

借用面向方面编程（AOP）的语言，您的架构也可能需要考虑“横切关注点”。这些问题/观点也应该通过您的架构视图来解决，在某些情况下可能是您自己的特定视图。这些担忧包括：

• 分层/分区
  
• 重用
  
• 质量和验证
  
• 准确性和及时性
  
• 可靠性，可用性，可维护性和性能
  
• 环境（绿色计算问题）
  
• 定制点
  
• 可消耗性（包括（de）安装的简易性，支持级别，可用性，......）
  
• 并发
  
• 安全
  
• 国际化
  
• 条例
  
• 维护，操作和支持问题
  

这意味着，任何担任架构师角色的人都需要拥有广泛的技能才能发挥作用，他们需要摆脱过度专业化的传统哲学，更多地是一个普遍化的专家。最低限度的是，他们应该从简单的数据架构师，安全架构师或网络架构师转变为架构师。仅仅是一名架构师也可能过于专业化，但这取决于具体情况。真正的专业人士力求拥有广泛的技能以及一个或多个专业。

15.这是如何工作的？

我所描述的架构方法与许多组织目前正在做的事情明显不同。表1比较并对比了许多组织中常见的架构实践与敏捷对应的架构实践。显然，这有很大的不同。敏捷方法之所以有效，是因为它专注于团队合作的人员。敏捷建模认识到人们是错误的，他们不太可能从一开始就获得正确的架构，因此需要有机会根据实施工作的反馈行事。当敏捷架构师是开发团队的高效成员，并且当开发团队参与开始的架构工作时，他们不需要全面的文档，导航图就足够了（授予，当这不是案件文件，希望最小，可能是必需的）。不需要架构评论，因为架构是通过架构原型设计/峰值的具体反馈来证明的，因为人们可以看到架构发展，因为您的模型公开展示供所有人查看。敏捷架构师有勇气专注于解决当今的问题并相信他们明天可以解决明天的问题（Beck，2000），以及认识到他们无法准确预测未来并因此选择不过度构建他们的架构的谦虚。

表1.比较常见和敏捷架构实践。

架构师们很受尊重，经常被放在基座上，甚至更糟的是，被放在基座上

16.解决敏捷和架构周围的神话

我想通过解决一些与世界各地的组织合作时仍然遇到的常见神话来结束这篇文章。

• 敏捷者不做架构。我的希望是，这篇文章将把这个神话牢牢地放在一边。
  
• 您需要进行详细的前期架构建模。您应该进行一些前期架构建模，以确定您的一般技术策略，识别您可能遇到的潜在技术挑战，并帮助您在团队中围绕技术方向达成共识。关键是你不需要很多细节来实现这些目标。采用“大型模型预测（BMUF）”方法是一种选择，这种方法在理论上听起来很棒，特别是如果你是一名专业建模师，但在实践中通常被证明是一个相当差的人。BMUF战略导致糟糕的决策和解决方案不太可能满足利益相关者的实际需求，降低您支持不断变化的需求的能力，并导致士气低落。
  
• 架构师负责架构。虽然许多组织选择支持主要负责架构活动的专业架构师，但事实证明这在实践中是一个相当糟糕的选择，因为开发人员可能会将架构师视为“象牙塔”并且经常会选择忽略它们。正如您在本文中看到的那样，有效的架构策略本质上是协作的，而不是独裁的。