敏捷与IT体系结构第2部分（英）
敏捷和IT体系 结构部分。2 JIT-JEA在行动 欢迎来到JIT-JEA在行动 在2022年1月发布了第一篇JIT-JEA（及时-恰到好处的架构 ）外部POV论文后，我们希望提供一些工作示例，不仅说明JIT-JEA的定义，还展示敏捷架构的“艺术”是如何实践的。 本文需要10个真实示例，涵盖“恰到好处的架构”、“恰到好处的文档”、“恰到好处的治理”、“及时”和“迭代大小块”。 KAI施罗德 全球架构师社区领导慕尼黑,德 贡纳门泽尔 主注册建筑师曼彻斯特,英国 斯特凡诺罗西尼 首席架构师意大利房产申诉专员署米兰 2敏捷和IT体系结构 tbleof 反对帐篷 介绍 04 示例1:架构推动者 06 示 例2:文档和代码(DaC) 08 样 本3：轻量级架构决策记录（LADR）10示例4：实现设计灵活性的架构样式12示 例5：行走骨架作为敏捷架构参考14个 样本6:建筑跑道16 示例7:DevOps护栏18样本8：用于快速评估架构替代方案的低代码20个样品9:设计系统22样 本10：贵公司或部门的技术雷达24结 束语JIT-JEA在行动26 参考书目27 作者28 3 JIT-JEA 足够的架构 介绍 足够的文档 足够的治理 只是在时间! 在迭代规模 CHUNCKS 我们将在本文档中分享10个具体示例，您可以利用这些示例来加速在敏捷环境中进行架构的实际方法。在下表中，我们将它们与JIT-JEA模型中的5个敏捷支柱进行了映射： N 。 样本 足够的架构 足够的文档 足够的治理 只是在时间! 在迭代大小的块 1 架构的推动者 √ √ √ 2 文档和代码 √ √ √ 3 轻量级的ADR √ √ √ √ 4 建筑风格 √ √ 5 行走的骷髅 √ √ √ 6 建筑跑道 √ √ √ 7 DevOps护栏 √ √ √ 8 较低的代码 √ √ 9 设计系统 √ √ √ 10 雷达技术 √ √ √ 免责声明：提供的示例仅用于说明目的，可能无法完全反映客户情况的具体背景。 4敏捷和IT体系结构 5 JI 足 示例1:架构推动者 T-JEA 够的架构 范围:Replatforming遗留应用程序 部门:保险 工具:JIRA 足够的治理 在迭代规模 CHUNCKS 将“恰到好处的架构”主题引入敏捷工作方式的一个实用方法是引入 敏捷待办事项列表的一种新任务，用于描述架构和技术主题。 安全这些类型的活动名称推动者并介绍了其中的四种类型：探索、体系结构、基础结构和合规性[SAFe推动因素]。 敏捷旨在通过业务功能提供价值，但是，还必须解决架构主题，以保证中期和长期结果。 产品负责人和敏捷架构师必须共同努力，在用户故事和推动因素之间决定适当的平衡，进入产品和冲刺待办列表。 在任务板上以用户情景的可视化方式显示启用程序可以使此任务更 容易，并使团队能够在这些内容上花费适当的精力。 推动者带来以下主要优点: •推动因素使架构和技术债务主题在积压工作中可见 •推动因素允许团队和产品负责人优先考虑架构主题和业务功 能，并以迭代大小的块开发它们 •借助推动因素，敏捷架构内置并集成到标准敏捷工作方式中 架构的推动者 推动者在行动: 对于一个重要的保险项目，我们扩展了用于跟踪业务用户故事的JIRA工具的配置。 我们创建了一个表示启用程序的新Jira事务类型，以及一个新的自定义字段来跟踪其不同类型—勘探、架构、基础设施和合规性。 我们决定以与业务案例相同的方式（使用相同的工 作流程和任务板）管理新的推动因素案例，避免创建“专用”任务板，并将推动程序任务的开发与其他活动集成在一起。 使用不同的卡片颜色有助于形象化 –从迭代规划活动开始–推动因素和用户故事之间的平衡。 因此，诸如“创建DevOps工具链的夜间构建”或“需要缓存组件的峰值”之类的活动在任务板中作为具有优先级和估计的基础结构和探索推动因素清晰可见 ，并且在迭代期间跟踪了它们的进度。 在迭代审查期间，我们展示了通过推动因素取得的结果，并跟踪了花费的时间百分比 与业务用户故事相比，推动因素案例。 示例2:文档和代码 JIT-JEA 足够的架构 (DAC) 足够的文档 在迭代规模 CHUNCKS 范围:Web应用程序部门:内部凯捷的产品 工具:GitlabMkDocs,HTML网站,咕噜 敏捷架构的口头禅是架构必须始终与代码同步。 “一切都作为代码”是敏捷和DevOps从业者普遍采用的原则，对敏捷架构很有用。它包括将用于管理源代码（审查、版本控制、分支、配置控制）的相同技术应用于与软件开发相关的所有其他方面：基础架构、环境配置、架构本身、DevOps管道以及文档[文档 代码)。 对文档使用纯文本格式，例如AsciiDoc、Markdown或LaTex，它们属于 最常见的是，我们可以利用源代码管理的强大功能，包括版本 控制、差异、合并等。 文档的源代码被处理以构建人类可读的格式，例如Microsoft Word和PDF甚至HTML网站。 文档即代码具有以下主要优势： •简单的降价格式有助于关注文档的内容和可读性，而不是其格式和美观性。 文档和代码(DaC) •该文档可以以简单、有效和协作的方式生成，并且可以随着时间的推移轻松更新和维护。例如：为每个敏捷迭代生成新版本 ，并遵循软件开发的相同生命周期。 •版本历史记录有助于了解谁应用了更改、何时以及如何应用了更改。所有团队成员完成的工作合并到一个文档中，可以进行审查、集成和验证。也可以管理发布工作流。 文档和代码在行动: 对于凯捷产品，我们创建并维护了技术文档，以跟踪与不同环境相关的所有配置。 我们还制作了用户手册和技术部分，以解释软件中应用的用户界面和计算规则的详细信息。此文档在研讨会期间定期共享，以向用户描述产品功能。 我们决定使用Markdown语言[Markdown语言]来格式化文档，利用Gitlab的内置功能自动以HTML格式呈现文档。 为了让开发人员能够在本地修改文档并立即看到其更改的效果，我们选择了Gollum[Gollum]作为降价编辑器和渲染器，与GIT完全集成。 我们还能够从降价中编译PDF文档，以用于每个文档的主要版本。 示例3：轻量级体系结构决策记录（LADR） JI 足 在迭代规模 CHUNCKS T-JEA 足够的文档 足够的治理 够的架构 范围:企业 在到达那里之前设想以及可预见的影响和后果。使用另一个字段 跟踪状态，包括建议、已接受和 拒绝。 我们建议添加标签以便能够对决策进行分类，例如按产品、组织 、决策类型等。这些标签充当过滤器，帮助轻松做出决定：搜索 行业:汽车和保险工具:Sharepoint 任何体系结构决策都必须以简单有效的方式进行跟踪和版本控制。最好经常更新轻量级信息 而不是可能很快过时的繁重综合文档。此外，这些决策不仅需要与IT共享，还需要与业务共享。 对于任何架构决策，我们只描述如何在可能的场景中采取它的背景 引擎是关键，以确保在团队中成功使用LADR。 由于决策可以随时间推移进行修订和更改，因此跟踪记录本身的更改非常重要，以便可以看到它在某个时间点的外观。 轻量级的体系结构决策记录(LADR) 使用正确的工具是轻松访问跟踪新记录和阅读过去决策的关键。如前所述，文档即代码是实现轻量级决策注册表的好技术，可确保快速轻松地访问以及跟踪更改和比较修订的能力。 可以在此处找到示例轻量级架构师决策记录（LADR）[LADR示例]。 LADR带来以下主要优点: •架构决策很容易通过组织进行共享和沟通。它们可以通过搜索引擎轻松找到。 •LADR通过使组织中的所有角色都集中精力和一致性来加快决策过程。 •LADR为您提供清晰的架构历史日志，否则该日志将隐藏在大型架构文档中。 LADR在行动: 对于来自汽车和保险行业的两个重要客户，决定以轻量级风格跟踪所有架构决策。 为了确保文档始终更新以跟踪团队做出的每个关键决策，我们增强了敏捷团队的“完成定义”，将更新的ADR作为软件开发生命周期的集成和强制性步骤包括在内。如果在分析或开发用户故事期间团队做出架构决策，则在正确创建或更新相关的架构师决策记录之前，故事本身不能被视为“完成”。 在每次代码发布之前，都会定期检查ADR注册表。 产品:… 状态:接受 IT部门:… 日期:… 业务部门:… 与会者:…,…,…,… 背景和问题陈述 为了提高ITSM效率，已经提出了一项功能，用于在工单达到SLA的50%或70%时生成警报。目 标是避免违反SLA票证。仪表板将帮助管理层确定所有事件的优先级并做出决策。 决定司机 … … 场景1:考虑场景… 场景2:… 决定和影响 … 汽车客户端的LADR示例（通过SharePoint网站） JIT-J 足够的架 范 部门:公共部门 编档 示例4：实现设计灵活性的架构样式 工具:Archi和权力的观点 围:电子 系统 EA 构 只是在时间! 新兴架构鼓励团队“及时”做出决策。因此，敏捷环境中使用的架构风格应该能够快速响应更改。支持敏捷性的一个原则是明确分离域和系统其他部分之间的关注点。 在将领域部分与其他部分分离时，域逻辑独立于任何技术方面 ，从而更容易更改或延迟技术决策，而不会影响域模型。 有不同的架构风格遵循明确分离关注点的想法。例子是Alistair Cockburn[HexagonalArchitecture]和CleanClean推广的六边形建筑风格 由RobertC.Martin[CleanCode]推广的建筑。这两种架构风格都表明域模型正在形成系统的核心，而不依赖于系统的其他部分。所有依赖项 定向到域核心，该域核心提供要由周围组件调用的接口（入站）以 及由域核心调用并由周围组件实现的接口（出站）。这些类型的体系结构样式对于新兴体系结构带来了一些可观的好处： 建筑风格使设计的灵活性 •延迟技术决策：由于系统的领域部分被很好地封装，团队可以在不依赖技术决策的情况下发展领域逻辑。这使得更容易将决定推迟到更负责任的时刻。例如，您可以启动一个完全没有数据库的项目，然后决定关系数据库还是NoSQL数据库更适合您。 •以较小的影响更改基础架构：使用面向内部的依赖项，您不必依赖 适配器实现。这使得更改或替换它们变得更加容易。例如，可以轻松地将REST适配器替换为gRPC适配器。 •业务逻辑的可测试性：由于系统的域部分独立于任何环境，无需使用基础设施组件即可实现高可测试性。 推迟的决策可以作为架构决策日志的一部分进行跟踪。 架构风格在实际应用中实现设计灵活性： 在一个具有高度不确定性和技术复杂性的公共部门项目中，使用六边形架构风格来保持域逻辑独立于数据库技术。最初不确定使用哪种数据库技术，该团队使用了一个简单而知名的数据库，同时推迟了决策。最终，团队获得了足够的信心，以最小的努力进行基础设施的改变。干净的域核心允许有效管理不同的技术，并通过添加特定的适配器轻松发展解决方案。业务逻辑的可测试性完全独立于技术增强，确保域逻辑随时的有效性。 入站端口 出站端口 内部 WebUI 01 其他适配器 PostgreSQL 适配器 PostgreSQL 域模型 02 入站端口 04 出站端口 入站端口 SOAP适配器 消息适配器 Apache卡夫卡 03 出现在 入站端口 出站端口 内部 WebUI 其他适配器 01 对象存储 适配器S3存储 域模型 02 入站端口 04 出站端口 入站端口 SOAP适配器 消息适配器 03 Apache卡夫卡 外部渠道 电子邮件适配器 示例5：行走骨架作为敏捷架构参考 工具：EclipseIDE，SpringBoot，Oracle11g b应用 行走的骨架是将“恰到好处的架构”主题引入敏捷工作方式的好策略 。 “行走”意味着工作，可执行和可测试，“骨架”意味着最小化和简化
