Axon Framework的应用正在迅速增加，最近达到了100万的下载量。在最近的阿姆斯特丹事件驱动微服务大会上，Allard Buijze在演讲中介绍了Axon的基本概念、历史和未来。该框架面向以DDD、事件源和CQRS为基础的系统。
Buijze一开始就指出，事件非常特殊；它们描述了发生过的事情，并且是系统历史的一部分。我们可以从过去中发现问题，我们可以设定对未来的期望。在Buijze看来，就是这点推动了事件源实践——使用事件作为应用程序的事实来源，而不仅仅是作为意外结果。
Buijze还指出，重要的是，服务在消费自己的事件——这在事件源中非常重要。如果服务是基于内部数据而不是事件进行决策，那么你所做的就不是完全的事件源。你有一个事件驱动的架构，但是你不能保证事件是服务中发生的事情的真实表示。
根据Buijze的经验，有很多基于实体服务的微服务架构，他将这种设计技术称为“名词驱动设计（noun-driven design）”。其思想是在描述新系统的文档中找出所有的名词，它们将成为服务，而所有的动词将成为API调用。这种技术很可能会导致分布式的大泥球，所有的服务都相互依赖。如果一个服务宕机，整个系统将无法使用。
Buijze希望我们从单体而不是微服务入手。尽管更难扩展，但它们更容易部署和重构。他指出，我们不应该将好的单体与大泥球混为一谈。他建议的策略是从单体入手，但要确保内部结构明确定义。随着时间的推移，当过多的人不得不使用代码的相同部分时，就应该提取出一些组件，最好不要修改其他部分。随着时间的推移和需求的增加，会有越来越多的组件被提取出来。
为了帮助提取组件，位置透明性非常重要，Buijze指出，Axon的主要特性不是CQRS，而是应用程序中组件之间的位置透明性。如果两个组件不知道它们各自的位置，那么你就可以修改那个位置。这还意味着，你不必知道某个操作在哪个服务中——你只需发送一条消息，它自己会找到它的目的地。
组件既不应该知道也不应该对与它交互的组件的位置做出任何假设。
事件很重要，但Buijze指出，组件发送的消息有三种类型，并强调，事件与消息不是一回事：
- 事件就是已发生的事情。它们被分发给所有处理程序，不返回任何结果。
- 命令是你希望系统执行的操作。它们会被路由到单个处理程序并返回一个结果。
- 查询用于你想知道什么的时候。它们会返回一个结果。
为了兑现位置透明的承诺，并使用这些不同类型的消息，AxonHub于2017年（在去年的大会上）发布。Buijze将其描述为一个消息传递平台，它能够理解不同类型的消息，而不是内容，并能够将不同的类型路由到正确的目的地。他指出，“集线器（hub）”的概念与微服务的智能端点和哑管道概念类似，虽然在本例中管道知道消息类型。
展望未来，Buijze相信，微服务将继续发展演化，他也相信，Axon组件的工作和通信方式在无服务器环境中会非常有用。他们朝这个方向迈出的第一步将是提供SaaS解决方案，但他也指出，他们还有更多的东西需要学习，为了有效地使用无服务器环境，他们还有更多的工作要做。
今年早些时候，Axon团队发布了AxonDB，这是一个专门设计的事件存储。AxonHub使用该存储存储事件，为此，他们已经决定将这两个产品合并到此次大会期间宣布的Axon Server中。该服务器既有开源版本，也有企业版本。
Axon的下一个版本4正在开发，第一个里程碑已于最近发布。产品发布预计在10月18日。
Axon Framework是面向JVM平台的开源产品，由Allard Buijze在2009年创建。2017年7月，一家单独的公司AxonIQ成立，专门从事Axon产品开发。