关键要点

1. 我们看到了对“进化架构”设计的更多需求，这种架构建立在先前关于可替换性设计和需要关注架构中“胶水”组件的讨论的基础之上。进化架构支持功能和跨功能需求和约束的未来变化。

2. 对“微服务”架构风格的认识可能正在进入后期多数，但“正确设计分布式系统”的相关主题，以及反应性和容错性的设计并未沿着采用曲线进行。

3. 我们推测，有些架构主题永远不会沿着采用曲线转移到早期多数或晚期多数，不幸的是，它们包括几种针对特定用例的高效模式，如基于事件溯源/ CQRS或基于Actor模型系统。

4. 我们越来越多地将“架构师”的角色视为越来越注重技术领导力，架构模式识别和框架意识，以及处理跨领域问题的设计。

5. 虽然我们认为术语“无服务器”可能含糊不清，但我们很欣赏有可能将重点放在设计事件驱动系统以及自动消除某些平台问题的可能性上，如果这是正确实现的

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• 微服务是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上的其他主题之间的重叠感到困惑，尤其是文化与方法。我想是责怪康威定律。关于架构的很多内容都归结为通信 – 进入和离开系统的外部通信点是什么内部服务将如何相互通信保存和访问我的数据p>

在许多方面，公司回答这些问题的方式以及他们可以选择的选项将基于他们在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上进行这次讨论！

原文：https://www.infoq.com/articles/architecture-trends-2019

http://pub.intelligentx.net/architecture-and-design-infoq-trends-report-january-2019

讨论:知识星球【数字化和智能转型】

文章知识点与官方知识档案匹配，可进一步学习相关知识Java技能树首页概览92701 人正在系统学习中