Axon很大程度上基於域驅動設計（DDD）和命令查詢責任隔離的原則。儘管對這些概念的完整解釋超出了本參考指南的範圍和意圖，但我們確實希望提供有關Axon應用程序上下文中最重要概念的摘要。
戰略概念
戰略概念是相對較高的概念，它們在體系結構級別上影響系統的設計。它提供了設計組件邊界及其之間相互作用的概念。儘管它們不會直接影響單個Axon應用程序的設計，但此類應用程序的邊界通常會受到這些概念的影響。
域和子域
在DDD上下文中，域的正式定義是：
知識領域，知識領域或活動領域用戶向其應用程序的主題領域是軟件的領域。
這個定義可能看起來很模糊，但確實很好地抓住了本質。域基本上是構建軟件的環境。這種環境由法律，最佳實踐，期望，傳統等組成，它們定義了什麼是重要的，什麼不是重要的。
域可能非常大，並且域內的不同區域可能會產生不同的影響。例如，在銀行業務領域，消費者銀行業務，公司銀行業務和財富管理之間存在明顯的區別。
有許多技術可以幫助您發現域。事件風暴是特別有趣的事件。它是一種研討會形式，用於快速探索複雜的業務領域。
模型
模型是：
一種描述領域選定方面的抽象系統，可用於解決與該領域相關的問題；
換句話說，模型捕獲了對於我們解決領域內特定問題的重要信息。這個定義本身表明一個應用程序應該包含多個模型，因爲每個問題都有一個不同的理想模型來解決。
有關基於Axon的應用程序中模型的某些構造塊的更多信息，請參見戰術概念。
界限上下文
上下文是：
單詞或陳述出現的設置決定其含義。
換句話說，相同的領域概念對不同的人可能具有不同的含義。
例如，考慮一次飛行的概念。對於乘客而言，飛行是指從飛機起飛到到達目的地的時間。但是，地勤人員關心航班到達登機口的次數，要登上飛機的飯菜，枕頭等的數量，這些事情在航班離開登機口時就完成了。對他們而言，出發時間是最後期限，而不是起點。
因此，對於模型和上下文有許多規則：
- 明確定義應用模型的上下文。
- 在團隊組織，在應用程序的特定部分內的用法以及諸如代碼庫和數據庫模式之類的物理表現方面，明確設置邊界。
- 在這些範圍內嚴格保持模型的一致性，但不要因模型之外的問題而分神或困惑。
上下文映射
有限的上下文永遠不會完全靠自己生存。來自不同環境的信息最終將被同步。顯式建模此交互很有用。域驅動設計列出了上下文之間的一些關係，這些關係決定了它們之間的交互方式：
- 夥伴關係（兩個環境/團隊共同努力建立互動）
- 客戶-供應商（具有上游/下游關係的兩個團隊-上游可以獨立於下游團隊獲得成功）
- 遵從者（上游/下游關係中有兩個團隊-上游沒有動力向下遊提供，下游團隊也沒有努力翻譯）
- 共享內核（明確共享模型的一部分）
- 分開的方式（將它們切開）
- 反腐敗層（下游團隊構建一層，通過轉換交互來防止上游設計“泄漏”到自己的模型中）
在基於Axon的應用程序中，上下文定義事件在其中攜帶值的邊界。有些事件可能僅在其發佈的上下文中才有價值，而另一些事件甚至在外部也可能有價值。發佈事件（或任何消息，就此而言）的範圍越廣，最終有更多的組件耦合到發送者。
戰術概念
爲了構建模型，DDD（在某種程度上還包括CQRS）提供了許多有用的構建塊。下面是一些在基於Axon的應用程序中很重要的構建塊。
Aggregates
聚合是始終保持一致狀態（在單個ACID事務中）的實體或實體組。
聚合根是聚合中負責維護此一致狀態的實體。這使聚合成爲在任何基於CQRS的應用程序中實現命令模型的主要構建塊。
DDD的正式定義是：
關聯對象的羣集，出於數據更改的目的，它們被視爲一個單元。外部引用僅限於聚合的一個成員，稱爲根。一組一致性規則適用於聚合的邊界。
在基於CQRS的應用程序中，聚合在命令模型中非常明確地存在，因爲這是啓動更改的地方。但是，查詢模型/投影也是由聚合建立的。但是，通常，查詢模型中的聚合要簡單得多，因爲狀態不變式在這些模型中通常不太嚴格。
Saga
並非每個命令都能在單個原子事務中完全執行。匯款是交易中經常出現的一個非常常見的例子。人們通常認爲，絕對必要的是原子交易，將資金從一個帳戶轉移到另一個帳戶。好吧，不是。相反，這是完全不可能的。如果資金從銀行A上的一個帳戶（BankAccount集合的實例A）轉移到銀行B上的另一個帳戶（BankAccount集合的實例B），該怎麼辦？銀行A是否獲得銀行B數據庫的鎖？如果正在進行轉帳，銀行A扣除了這筆金額但銀行B還沒有存入這筆款項，這很奇怪嗎？不完全是，它正在進行中。另一方面，如果在將錢存入銀行B的帳戶時出了點問題，銀行A的客戶會希望退回他的錢。因此，我們確實希望最終會有某種形式的一致性。另一個示例可能是GiftCardPaymentSaga，它會在下訂單（OrderPlacedEvent）後開始。它將確保一旦成功兌換禮品卡（CardRedeemedEvent），在另一側確認訂單（ConfirmGiftCardPaymentCommand）。
儘管在某些情況下ACID交易不是必需的，甚至是不可能的，但仍需要某種形式的交易管理。通常，這些事務稱爲BASE事務：基本可用，軟狀態，最終一致性。與ACID相反，BASE事務無法輕鬆回滾。要回滾，需要採取補償措施來還原在事務中發生的任何事情。在禮品卡示例中，禮品卡的兌換失敗將拒絕訂單付款。
在CQRS中，可以使用Sagas來管理這些BASE事務。它們響應事件並可以調度命令，調用外部應用程序等。在域驅動設計的上下文中，通常將Sagas用作不同聚合（或聚合實例）之間的協調機制，以最終實現一致性。
View Models or Projections
在CQRS中，視圖模型（也稱爲投影或查詢模型）用於有效地公開有關應用程序狀態的信息。與命令模型不同，視圖模型着重於數據而不是行爲。視圖模型通常是爲適應特定受衆的信息需求而建模的。這些模型應清楚地表示模型的目標受衆，以防止“分心”和範圍蠕變，最終導致可維護性甚至性能的損失。