关键要点

1. 我们看到了对进化架构设计的更多需求，这是基于之前关于可替代设计和胶组件的讨论。进化架构支持未来功能、跨功能需求和约束的变化。

2. 对微服务架构风格的理解可能进入后期，但分布式系统正确设计的相关主题以及反应性和容错性设计并未沿曲线进行。

3. 我们推测，一些架构主题永远不会沿着曲线转移到早期或晚期。不幸的是，它们包括几种针对特定用例的 CQRS或基于Actor模型系统。

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

5. 虽然我们认为术语无服务器可能含糊不清，但如果这是正确的，我们很欣赏设计事件驱动系统并自动消除某些平台问题的可能性

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

本文总结了我们目前对架构与设计的看法（A＆D）该领域侧重于基础设施模式、技术框架模式的实现，以及软件架构师必须培养的设计过程和技能。

自从我们上次审查这个主题以来，微服务已经进入了后期的大部分，但我们的内部讨论也强调，与正确设计分布式系统密切相关的主题，以及反应性和容错性设计不是沿着曲线进行的。Gartner在炒作周期中，我们可能接近微服务幻灭低谷的底部。

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

虽然我们认为无服务器这个词有点模糊，但我们欣赏设计模块化、事件驱动系统和自动化几个基本操作平台的可能性。在一个相关的主题上，我们也看到了更多关于支持未来需求和限制变化的进化结构的讨论。

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

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

以下是三个InfoQ内部聊天记录的轻微编辑副本是架构与设计主题编辑之间的相应内部聊天记录，为我们提供了更多的上下文。

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

作为十人的首发，我觉得HTTP2转向早期用户（EA），HTTP进入创新者。 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从角度讨论主题的演示可能是个例外。

• GraphQLI或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或I密切相关且密切相关EA例如，值得提及追溯性值得提及EA / LM。然而，我不认为这些子主题可以包括在内AD主题图中。

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

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

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

InfoQ编辑团队的建立是通过招聘和培训专家从业者来撰写新闻和文章，并分析当前和未来的趋势。通过编辑页面申请成为编辑，并参与对话。

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

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

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