关键要点

我们看到了对“进化架构”设计的更多需求，这种架构建立在先前关于可替换性设计和需要关注架构中“胶水”组件的讨论的基础之上。进化架构支持功能和跨功能需求和约束的未来变化。
对“微服务”架构风格的认识可能正在进入后期多数，但“正确设计分布式系统”的相关主题，以及反应性和容错性的设计并未沿着采用曲线进行。
我们推测，有些架构主题永远不会沿着采用曲线转移到早期多数或晚期多数，不幸的是，它们包括几种针对特定用例的高效模式，如基于事件溯源/ CQRS或基于Actor模型系统。
我们越来越多地将“架构师”的角色视为越来越注重技术领导力，架构模式识别和框架意识，以及处理跨领域问题的设计。
虽然我们认为术语“无服务器”可能含糊不清，但我们很欣赏有可能将重点放在设计事件驱动系统以及自动消除某些平台问题的可能性上，如果这是正确实现的

InfoQ和QCon都关注我们认为属于“创新者，早期采用者和早期多数阶段”的主题。我们尝试做的是确定适合Geoffrey Moore所谓的早期市场的想法，其中“客户群由技术爱好者和有远见的人提供，他们希望领先于机遇或迫在眉睫的问题”。我们也在寻找可能“跨越鸿沟”的想法，以便更广泛地采用。在这种情况下，或许值得一提的是，技术在采用曲线上的确切位置可能会有所不同。例如，湾区公司在这一点上广泛采用微服务，但在其他地方可能不太广泛采用，也许不太合适。

本文概述了我们目前如何看待“架构和设计”（A＆D）领域，该领域侧重于基础架构模式，技术框架中模式的实现，以及软件架构师必须培养的设计流程和技能。

自我们上次审查这一主题以来的显着变化包括“微服务”进入后期多数，但我们的内部讨论还强调，“正确设计分布式系统”的密切相关的主题，以及反应性和容错性的设计并不是沿着采用曲线。对于Gartner炒作周期，我们可能正在接近微服务“幻灭的低谷”的底部。

我们还推测，架构领域永远不会沿着采用曲线走向早期多数或晚期多数，不幸的是，它们包括几种高效模式 - 例如基于事件溯源/ CQRS或Actor 模型 - 基于系统 - 可以为某些组织和业务问题提供高效的解决方案。

虽然我们认为“无服务器”一词略显模糊，但我们很欣赏将重点放在设计模块化，事件驱动系统以及自动化几个底层操作平台问题的可能性上。在一个相关主题上，我们还看到围绕对支持未来需求和约束变化的演化架构的需求的更多讨论。

我们越来越多地看到“架构师”的角色正在变得更加专注于软技能，例如技术领导，除了现代技术技能，如架构模式识别和框架感知，以及处理跨领域问题的设计。

对于上下文，这是2018年下半年主题图的样子.2019版本位于文章的顶部。

以下是三个InfoQ架构和设计主题编辑之间相应内部聊天记录的轻微编辑副本，它为我们在采用图上的推荐定位提供了更多上下文。

Daniel Bryant，独立技术顾问，Datawire产品架构师和InfoQ新闻经理：

作为十人的首发，我认为HTTP2转向早期采用者（EA），HTTP3进入创新者。 GraphQL（以及可能的gRPC）可能是EA（或创新者？）。我也认为Chaos Engineer属于DevOps队列。微服务可能是晚期多数（LM），BDD，DDD和TDD也是如此。

我很想看到“进化架构”出现在某个地方 - 可能是EA？那么“架构师作为技术领导者”（强调角色的非技术演变）呢？

我有兴趣听听您的想法，并询问我们是否需要移动，添加或删除主题？

Jan Stenberg，IT顾问，在.Net / C＃和JVM / Java平台上构建系统超过25年：

我认为架构与设计（AD）在某种程度上与我们在InfoQ上讨论的其他主题不同。

在AD中，我们没有新的或更新版本的架构的常规基础。相反，由于新的工具，框架或智能架构使其成为可行，现有的想法再次流行，并且可能打包和品牌化。

我们也有可能适合两个队列的区域。在更高级别，它们可能适用于AD，而更多技术部分适用于另一个队列。我认为无服务器就是一个例子，在更高层次上它是AD的一个重要领域，技术部分可能属于云队列。微前端和类似技术是另一个例子，它是AD还是HTML5和JavaScript？

还有一些我认为永远不会在EM或LM中出现的领域或架构，不幸的是，它们包括我最喜欢的几种架构，如基于事件源/ CQRS或基于Actor模型的系统。我认为他们在可预见的未来将是少数人使用的小众架构。我不确定我们应该如何应对这些问题，也许它们会在架构师和开发人员不再谈论它们时消失？

所以，我对AD未来的看法（或许我的希望）：

无服务器。从我去年听过的演讲中，我的印象是，这将越来越自动化，对底层基础架构的工作量减少。

像Camunda这样的工作流程平台。我认为它们在具有更复杂业务逻辑的微服务或分布式系统中非常重要。

事件溯源/ CQRS。我希望它会变得更加主流。可能是EA或EM。

事件驱动的体系结构。 EA或EM。

Actor 模特/反应。去年我和Vaughn Vernon讨论了这件事，他相信有一天它会成为主流，但我对此持怀疑态度。

进化架构很有趣，我认为EA是正确的。

混沌工程。是的，通常它是DevOps，从AD角度讨论主题的演示可能是一个例外。

GraphQL和类似的工具是I或EA我认为，取代REST（希望也正确实现）。

架构师为技术领导者。我一直在与家里的各种架构师会面，其中许多人的主要工作是让商业/政府领域专家了解他们自己的领域。但也许它更像是一个敏捷队列故事？

微服务是LM。（我认为微服务很快将成为“今天的SOA”。许多人正在以一种好的方式使用它们。太多人将标签放在分布式整体上）。

DDD是晚期的多数，但我希望它仍然是InfoQ的一个有趣的主题。

BDD是迟到的多数或相当“迟到的少数民族”

TDD仍然有一些或多或少有趣的讨论。太少或太多，单元测试或黑盒测试，Ice-cream cone 或什么，但LM，至少。

当我在日常生活中遇到架构师，开发人员，领域专家和其他人，而不是在会议和类似的活动中，我经常意识到我们在这里讨论的许多概念对于他们来说是未知的或非常分散的，这也使得他们看到了InfoQ的好处。我记得大约两年前我在开发者大会（我认为是在加拿大）听过的一个演讲，其中Vaughn Vernon询问了多少人对DDD有所了解，大约一半的观众举起了手。

当我开始为InfoQ编写时，我写了一些关于框架和库的更新，我认为这些功能可能会影响架构，但随着时间的推移，我的写作越来越集中在有趣的博客文章和演示文稿上，只有几个项目关于像Axon，Akka和其他我认为与特定架构密切相关的框架。

在QCon会议期间进行这种讨论会很棒。

InfoQ主编Charles Humble：

我和Vaughn Vernon一起关于Actor 模特 - 并认为它很可能成为主流 - 直接或通过消息传递等方式。在JVM领域，Akka在推广这种方法方面做得很好，基于消息传递的系统长期以来一直是在金融系统中像Actor 一样做事的流行方式。

Actor 似乎很容易被人们掌握和推理，也是处理大规模并行工作的好方法。我希望看到Ponyas周围的势头成为一个现代的，基于Actor 的系统的例子，但我不得不说我认为这不太可能。

关于进化架构，我有兴趣听到马丁福勒去年在播客上谈到这个问题，并且他参加了极端编程。我很期待阅读这本关于Thoughtworks的书。

Thomas Betts，IHS Markit首席软件工程师和InfoQ Architecture Queue负责人：

在很高的层面上，我同意丹尼尔提出的大部分内容。 Jan是正确的，一些架构模式非常适合主题图的自然进展，而其他架构模式可能永远不会超越早期采用者阶段，因为它们不是广泛适用的。

我有时会对A＆D与InfoQ上的其他主题之间的重叠感到困惑，尤其是文化与方法。我想是责怪康威定律。关于架构的很多内容都归结为通信 - 进入和离开系统的外部通信点是什么？我的内部服务将如何相互通信？如何保存和访问我的数据？

在许多方面，公司回答这些问题的方式以及他们可以选择的选项将基于他们在A＆D和C＆M的采用生命周期曲线上的位置。我想说A＆D是等式的技术方面，而C＆M是非技术性的，但这似乎过于简单化了。此外，技术实现可能会落入开发和/或语言队列中。 A＆D处于两者之间的软弱处，处理交叉问题，希望为如何实施该系统提供指导。

我将停止哲学咆哮，并添加一些具体的讨论要点。

无服务器 - 虽然我个人不喜欢这个术语，因为它似乎没有任何特定的含义，无需服务器，可能在EA中。

反应性 - 可能是EA。我认为反应式架构会变得更加普遍，因为开发人员熟悉反应式编程，特别是在JavaScript中。那可能是尾巴摇着狗。

DDD - 虽然DDD本身可能会转向LM，但有许多衍生创意与DDD密切相关，并且在I或EA中。例如，事件溯源值得提及为EA / LM。但是，我不认为很多这些子主题可以包含在AD主题图中。

微服务 - 在那里使用“无服务器”作为一个常被滥用或误解的术语。我认为这是在广泛采用方面进入后期多数，但可能只是EA用于稳固的分布式架构。

分布式系统 - 我不认为将其作为主题图上的项目是有效的，因为它太宽泛了。但是我想看到我们谈论设计时考虑到分布。像反应性和容错性这样的想法对于强大的分布式系统至关重要，而这种方式在整体结构中并不重要。这将是在A＆D主题图上留下混乱的论点。

我完全支持在QCon上进行这次讨论！