CQRS和事件源框架Axon的基本概念和未來
Axon Framework的應用正在迅速增加，最近達到了100萬的下載量。在最近的阿姆斯特丹ofollow,noindex" target="_blank">事件驅動微服務大會 上，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產品開發。
檢視英文原文：Basic Concepts and the Future of Axon, a CQRS and Event Sourcing Framework