连续架构六大原则 - Murat Erder

Murat Erder

连续架构六大原则

• 连续架构不是一种架构方法。这真的是一种心态，几乎是一种工作方式，一种思维方式。
  1. 第一个是你应该架构你的产品。很多人会考虑我需要实施的项目，但您应该考虑我正在实施的软件产品是什么，以及它的旅程是什么。
  2. 第二个是“关注质量属性而不是功能需求”。我们需要系统的非功能性需求：安全性、可扩展性、弹性、性能等。因为这些是真正测试您的系统或架构的关键因素。我们有时只在遇到大问题时才会处理它们。
  3. 第三个原则是“延迟设计决策，直到它们绝对必要”。
     • 架构的核心单元是设计决策，您必须在正确的时间做出决策。这是我们从敏捷世界中汲取的原则。
     • 你不能预先做一个大的设计。您必须尽早发展并做出关键决定，但将某些决定推迟到以后。因为如果你不这样做，那么你最终会过度设计你的系统。
• 原则四是“架构变革，利用小力量”。这就是松散耦合的内部相干组件。想想你的架构会在哪里改变，有松散耦合的独立组件。
• 原则五是“构建、测试、部署和操作的架构师”。在构建系统时，不要只考虑已实现的架构，还要考虑如何构建它、如何测试它、如何部署它以及如何操作它。
• 原则六是承认康威定律，即“系统设计后团队的模范组织”。这有两个方面。
  • 一个是敏捷世界，我们真正相信跨职能团队。不要有独立于应用程序开发团队和测试团队的独立数据库团队。我们想避免那些内部连贯的事情。
  • 对此的更宏观解释是承认您在组织中的地位以及您拥有哪些组织结构。因为康威定律说，每个软件系统或每个系统都将反映构建它的组织的通信结构。

数据模型的重要性

这是关键。有两个方面。

• 一是共同通用语言。还有领域驱动设计中无处不在的通用语言。
  • 当你说话时，我们必须有共同的语言。不仅是开发软件的团队，还有与业务利益相关者的通用语言。这很重要，因为如果您不会说一种通用语言，就很难理解您正在解决什么问题。
  • 如果你不定义它——它不必是一个详细的模式或 DDL，它实际上只是有一种共同的语言可以与之交谈，你最终会在循环对话中——你可能会实现不符合业务需求。拥有一个软件产品的通用语言，实际上是跨越你支持企业的软件产品，是非常重要的。
• 第二个方面是针对每个数据实体，了解哪个应用程序在掌握它，哪个应用程序正在使用它。
  • 同样，这是一件非常简单的事情，但是如果您不预先考虑它，您最终可能会在多个应用程序之间出现非常令人困惑的数据集成点以及我们所谓的数据菊花链。
    • 您从另一个应用程序获取数据，稍微修改它，然后将其发送到第三个应用程序。他们修改了它，然后将其发送给第四个。在您知道之前，没有人真正考虑过谁拥有哪些属性或哪些标识符，结果一团糟，因为您开始查看它们，实际上您的业务表现不一致。

数据技术趋势

• 我在金融服务和制药领域看到的一个趋势可能更多，它不是技术趋势，而是专注于数据治理。正确定义数据并确保业务利益相关者拥有该数据的所有权。
• 如果你仔细想想，有两种类型的系统。有更多的操作系统和更多的数据分析系统。我认为带有微服务的操作系统以及我们讨论过的事情；我们知道如何更好地构建它们。
• 但是当你看到一家公司时，就会出现这种大分裂，然后你的数据分析世界曾经是大数据仓库，一些专有的像 Teradata 之类的东西，然后我们进入了 Hadoop 世界，每个人构建数据湖，您可能会应用新技术，但这仍然是一个整体。
• 一个大趋势是来自 ThoughtWorks 团队的数据网格概念。这非常强大，因为它涉及应用与为数据架构构建操作系统相同的概念。它应用了我们的一些核心原则，因为您开始将这些数据视为一种产品。也讲了很多原则六，就是团队的组织。
  • 这些大的传统数据分析基础设施的挑战在于，您拥有各种专家，而这些专家是集中的，他们必须管理一切，而且他们没有足够的领域知识，因为技术是如此专业。这些专家专注于这一点。
  • 因此，当您尝试实施此数据网格概念时，即以某种方式围绕数据产品创建组件时，您还希望确保这些团队具有技术知识，或能够访问该技术知识以支持他们的数据产品。
• 最终的一致性很有趣，它已经存在了很长一段时间。事实上，如果你仔细想想，我们的现实生活最终是一致的。同样，这是您正在构建的应用程序类型。
• 你必须思考什么是对的。拥有一个符合 ACID 的数据库有一个非常强大的地方，您相信它可以为您管理应用程序的状态。这是一个非常强大的工具。因为一旦你离开那一刻，你就必须自己做更多的工程。你不得不说，由于我正在构建的软件产品的性质和我想要的质量属性的性质，我进入了一个更加分散、最终一致的世界，这是值得的。

数据作为架构关注点

• 数据是一个有趣的话题。我们经常使用它。几乎失去了意义。我们所说的数据是什么意思，您如何将其可视化？
• 我们拥有的数据将永远比系统更长寿。因此，数据是我们运营方式的核心。
• 过去 10 年发生的一个重大变化是引入了新的数据库技术。20-25 年前，如果您构建了一个系统，那么您将拥有一个关系数据库几乎是毫无疑问的。最大的争论是我是使用 Oracle 还是 Sybase，还是 SQL，不管它是什么。
• 现在，主要是由于处理大规模互联网问题的大型科技公司，那里有很多新的，不仅仅是 SQL 解决方案。它们解决了许多优秀的技术方面，但与过去相比，您的数据已更多地集成到您的架构中。如果您使用键值存储、文档存储或图形存储，它确实会影响您对应用程序及其运行方式的看法。它真正涉及我们预先设置的质量属性。
• 这些是更难改变的事情。你可以拆分你的组件，你可以做很多事情，你可以重构你的代码很多。但是改变你处理的底层数据结构和你做出的一些决定是基本的。它们比过去更具侵入性。

基本活动

基本活动解决了一个问题：什么是持续架构？做好架构是什么意思？必不可少的活动，如果你什么都不做，你必须做这四件事。您可以根据需要绘制任意数量的图表，也可以绘制任意数量的图表。你可以像这样、那样地组建你的团队。但这是要说的四件事，“我在做一个架构。”

• 有这四个组件，它们是架构决策、技术债务、质量属性和反馈循环。
  • 主要的是架构决策。这是您作为架构师的核心工作单元。你知道你正在做的决定和你没有做的决定以及它们的影响。
  • 第二件事是你必须了解你的技术债务。我在当前平台上的技术债务是什么？当我做出决定时，我是在减少还是增加技术债务。因为这是您对产品可持续性的长期看法。
  • 第三件事是质量属性。您必须关注质量属性。您必须确保从可扩展性、弹性等方面了解您的需求，并且您必须围绕这些事情构建测试工具，并了解您满足它们的程度。
  • 最后，它实现了反馈循环。这是最重要的事情。你建立团队的方式和你的发展方式，你应该尽快获得所有这些方面的反馈循环。

原文点击标题

作者Murat Erder 是德意志银行人力和采购部门的首席技术官。他在软件行业拥有超过 25 年的经验，包括软件供应商、管理咨询公司和大型国际银行，他在其中担任过开发人员、软件架构师和管理顾问。Murat 的主要专业领域是数据、集成和架构/CTO。Murat 是两本关于软件架构的书的合著者，《持续架构：敏捷和以云为中心的世界中的可持续架构》和《实践中的持续架构：敏捷和 DevOps 时代的软件架构》，他提出了在多个会议上就该主题进行了讨论，包括 SEI Saturn、O'Reilly Software Architecture 和 GOTO London。