arc42-method

arc42方法

系统和过程无关于适当的解决方案。
(Systematic and process-agnostic to appropriate solutions.)

arc42为以下两个问题提供了实用的答案,并且可以轻松定制以满足您的特定需求:

  • WHAT 关于我们的架构,我们应该沟通/记录什么?
  • HOW 我们应该如何沟通/记录?

架构和开发中的方法程序应该始终是迭代的:始终(!)通过系统反馈补充和伴随分析和建设性任务。

持续学习

让我们从一个基本和无所不在的任务开始:我们(更确切地说:所有从事IT开发工作的人)正在处理一个非常有活力的行业,
不断新技术、方法、图书馆、框架和方法。在设计、实施和运营IT系统时,我们必须考虑到这些创新,或者至少能够评估它们
对我们当前系统的影响。

从我们的角度来看,只有将独立学习作为一项基本行为,我们才能做到这一点。由于互联网和无所不在的信息访问,我们有机
会做到这一点;我们只需要为自己适当地使用它。

澄清需求

开发团队需要一个目标、要求和制约因素的强大和可持续的基础,以便能够做出有针对性的决策和发展。

软件架构师可以通过质疑质量要求、对功能需求进行分类和识别技术风险等方式为澄清需求做出决定性贡献。

v

设计结构

用较小的部分构建系统(arc42使用砖头一词,因为它是技术中立的)是架构和开发的基本任务之一。

(静态)构建块视图及其(动态)对应运行时视图属于此任务的范围。还包括接口、构建块或我们的系统与外部世界(外部接口)
之间的连接。

设计横截面概念

总体决策,例如选择开发或运营的基本技术,选择基础设施,甚至使用的框架或库——这些都是arc42所理解的交叉概念。这些概念
可以对单个或所有构建模块产生直接影响。它们可以是多次使用或全面使用的架构或设计模式。概念也可能与其他主题有关,例如
构建、部署、测试和/或发布系统的技术和方法。

arc42建议了整个动物园的主题,您可以(但不必)解决整个架构的问题-以下是一个小示例:

  • (图形)用户界面是如何结构和实现的?使用了哪些库或模式?
  • 如何、何处以及用什么持久化数据存储、分发和再次读取?使用哪些数据库?
  • 如何实施业务、验证或合理性规则?
  • 系统及其构建块如何处理错误或异常情况?
  • 系统如何处理日志记录和日志记录?

更多详细信息可以在arc42模板的第8节中找到…

通信和文档架构

您应该与相关利益相关者协调您的架构和设计决策,征求他们的反馈,并酌情将其纳入其中。您应该以书面形式做出一些决定:取
决于行业、系统类型、临界度、风险和/或流程模型,有时更多,有时更少。

一般来说,我们建议就架构决策进行深入的口头沟通,特别是与开发团队和开发团队内部。为此,您应该尽可能少地以书面形式记
录:书面形式为未来的更改创造了维护开销,许多团队对此犹豫不及,这是可以理解的。

arc42模板既适用于非常稀疏、非常详细和详尽的文档。

伴随实施

在开发迭代期间,您与您的团队进行了大量讨论,并进行了彻底的协调。你(希望一起)设计了构建模块、界面和概念——简而
言之:你一切都做对了。

不幸的是,这种良好的沟通是不够的:可能偏离讨论、讨论甚至记录的决定会潜入实现,即进入源代码:

无论这是故意还是意外发生,您都应该始终与您的团队合作,以确保源代码按预期实现结构和概念。检查决策是否得到适当执行
或是否具有您想要的效果。

顺便说一下,有时单个开发人员甚至有比架构组更好的想法-您可以通过系统地伴随实现并使其成为架构的一部分来找到实现的
黄金部分!

另一方面,开发人员也可能误解设计决策或概念,或实施得不当。在这种情况下,您应该指导并向受影响的人解释决定或概念,
或帮助他们实施这些决定或概念。

无论如何,您应该查看系统的源代码(=代码审查),并将实际实现与所需的目标进行比较。只有通过这项(详细)工作,您才
能真正看到架构决策是否以及如何最终实施。

特别是在较大的团队中,一个人不能再查看已创建或更改的所有源代码。代码分析工具可以提供帮助,但在基本情况下(系统的
关键或重要部分),人们应该进行此类审查(只有他们才能询问原因并根据情况进行评估)。通常,检查源代码的一小部分也足
够了,以将这项任务的努力保持在合理的限度内。

分析和评估架构

问问自己,作为一名软件架构师:定期询问你的决策和概念是否达到了预期的效果,或者从今天的角度来看,是否仍然合适。这
个简单的反馈循环构成了迭代(现在称为:敏捷)过程的基础。计划-做-检查-行动周期(PDCA或Deming圈)将系统审查(检
查阶段)提升为一个系统,这是有充分理由的:只是不加反思地行动和决定,不回头,很容易导致错过目标和行动主义。因此,
看看有条不紊的后视镜,并不时对您的系统、您的架构和设计决策、您的概念等进行有条不紊的审查。

在最好的情况下,您(或开发团队和其他受影响的利益相关者)仍然认为所有决策都很棒-然后继续前进!在其他情况下,分析
和评估允许您在早期阶段识别可能的弱点或风险,并计划和启动适当的改进措施。