事件存儲（事件源）中的事件通常以序列化格式持久化，其版本通過版本表示模型或模式中事件類型的更改。我一直無法找到顯示實際事件的實際模型或模式的好文檔（如果使用RDBMS，通常在事件存儲架構中的data表），但理解它理想上應該是通用的。事件存儲中的事件模型或模式
什麼是事件中最基本的字段/屬性？
我已經考慮過使用json-api作爲我的事件的規範，但也許這太「重」了。我看到的好處是靈活性和成熟度。
我正走向「錯誤的道路」嗎？
任何明確定義的例子將不勝感激。
我已經打算使用json-api作爲我的事件的規範，但也許這太「沉重」了。我看到的好處是靈活性和成熟度。
我是否正走向「錯誤的道路」？
不要忽視向前和向後兼容性。
您應該計劃檢查Greg Young的書event versioning;它並不直接回答你的問題，但它確實涵蓋了很多關於解釋事件的基礎知識。
簡答：幾乎所有東西都是可選的，因爲您需要稍後才能更改它。
您還應該查看Hohpe的企業集成模式，特別是他在messaging上的工作，該工作詳細介紹了許多您可能關心的案例。
de Graauw的Nobody Needs Reliable Messaging幫助我解釋了一個重要的觀點。
總結：如果可靠性對業務級別很重要，請在業務級別進行。
因此，儘管有一些你可能想要做的元數據跟蹤的一些有趣的片段，領域模型是真的只打算看數據;並且這將趨向於特定於您的域名。
您也有樂趣，你在產生，它與其他服務共享它們可能不匹配的表現，特別是可能不是獲得廣播相同的消息服務使用事件的表示。
我通過一項練習，試圖找出訂閱者查看事件所需的最少量信息，以瞭解其是否在意。我的答案是一個id（我之前看過這個特定的事件嗎？），一個標記，告訴你消息的語義含義（是我關心的東西？）和一個位置（URI），以便獲得更豐富的表示是我關心的事情。
但在域之外 - 例如，當您將系統作爲一個整體來研究發生了什麼時，具有相關標識符和因果標識符，時間戳記，源位置的簽名以及所以保存在元數據中的一致位置可以有很大的幫助。
只需使用映射到Json的基本類型進行建模就可以很方便地進行編寫。
你可以花大量的時間產生過於複雜的模型，如果你扔掉它太多的工具 - 比如Apache的節儉和/或Protocol Buffers的（或派生的東西）將提供各種各樣的IDL機制爲您生成意外複雜性。
在.NET土地和許多其他平臺上，如果命名空間中的類型，你可以做從類型
個人各種預測，我使用記錄和下游用戶在F＃的設計和代表性工具
types.fs擁有他們所需要的
除非你故意要一個通用的答案，否則你可以添加一個如.net這樣的標籤嗎？事件存儲意味着neventstore - 如果您的意思是Greg Young的GES，則有'get-event-store' –
事件存儲和事件模式不依賴於.net或neventstore。 – GregL83
我非常瞭解這一點。重點在於，無論是好的還是更糟的，標記事件存儲並不意味着你的想法 - 它意味着一個.NET存儲[通常用於SQL DB]。我沒有問題，你想要一個通用的答案 –