我正在構建一個非常以數據爲中心的系統。我有大量的分層數據集，但沒有業務規則。系統的輸出來自對數據和大量報告進行的一些計算。我需要有一個完整的審計追蹤（出於監管原因），並能夠從過去的任何時間點對數據集運行計算。CQRS +沒有DDD的事件採購
由於這些原因，我認爲有一個使用CQRS的事件源系統是最好的選擇。我見過的所有例子都是圍繞創建聚合來實現ES。我遇到的問題是因爲每個數據都是一個大的相關集，我只有少量的大量聚合。替代方案似乎將設置分解爲各個部分並將每個部分稱爲一個整體。但是，爲了做任何計算，我將不得不加載成千上萬的聚合。
我的問題是，有沒有人有CQRS + ES系統的經驗，是以數據爲中心的，可能看起來像什麼？
有沒有更好的方式來存儲數據集的歷史，而不使用ES？
感謝您的任何幫助。
自從我熟悉事件採購理念後，我總是使用事件存儲來存儲我正在使用的系統中發生的事情。我把它稱爲'事件採購簡化'，當你沒有真正構建集合，而是遵循貧乏的模型路線時，只需將所有邏輯放入應用程序服務層（如在洋蔥中）即可。
我很少看到在「精簡版」版本中不遵循「事件採購」的原因。這就像審計+日誌記錄一樣，但隨着代碼的增長，它的應用範圍會更好。 只有當您的域名豐富時，您可以考慮開始構建聚合和快照，將它們緩存在內存中等。對於淺域，如果您需要最大性能和巨大負載，也可以使用聚合。正確構建ES聚合需要技能和時間進行分析和實驗。確保你擁有它，在開始這個冒險之前。
感謝您的迴應。所以，我有一個Asset對象（在這種情況下采購Lite的想法），並且我有使用AssetId關聯到特定資產的Equipment對象。這兩個對象是不同的貧血模型。我正在使用CQRS，並且在我的命令處理程序中，我想遍歷特定資產的所有設備。如果我只能通過其ID在命令端加載對象，我怎麼知道要加載哪個設備？ – Colin 2015-03-20 08:18:07
我是否將所有ID存儲在資產中？我是否使用我的讀取模型來存儲AssetID和設備的查找？我讀過你不應該在命令處理程序中使用讀取模型，因爲它不能保證一致。有什麼想法嗎？ – Colin 2015-03-20 08:18:09
我通常首先以經典的方式實現一切（洋蔥，貧血模型，rdbms），所以你的命令是一致的，一切都按預期工作。您還可以編寫和自動化負載測試，以更好地瞭解性能瓶頸。然後你可以開始考慮優化高頻命令和查詢。你可能會考慮實施CQRS和「ES滿」的一些。 – IlliakaillI 2015-03-21 14:48:30
但是，爲了做任何計算，我將不得不加載成千上萬的聚合。
語言檢查：聚合只存在於寫模型（C）中。計算和報告來自讀取模型（Q）。畢竟，當您報告事件時，您不會更改/追加事件歷史記錄。
這是一個資產管理系統。每個資產都有10萬多件設備。
這聽起來有點像庫存跟蹤系統。格雷格楊說過「in most inventory systems there are no commands.」
因爲「記錄簿」是現實世界，而不是模型，「命令」沒有意義 - 模型不允許拒絕現實。沒有命令，聚合就會消失;沒有商業規則可以執行。只是宣佈改變現實世界的事件。
CQRS + ES的基本模式仍然有效，也就是說您將事件的歷史記錄寫入持久層（這是您的審計線索），並將事件從此記錄中發佈出來，以便您的其他預測可以更新。
您需要考慮有多少事件流適合您的情況。在CQRS解決方案中，域模型是記錄簿，每個聚合通常寫入獨佔事件歷史記錄（減少爭用）;需要來自多個流的數據的模型將它們連接在一起。所以你可能想爲你的不同外部事件源做類似的事情。或者，也可以將它們全部發布到單個事件流中，然後讓讀取的模型過濾掉不需要的事件。
我喜歡在CQRS + ES上閱讀你的答案，@VoiceOfUnreason – janhartmann 2016-04-25 11:42:25
如果沒有關於數據集有多大的細節，很難回答。計算如何發生等。 – 2015-03-19 12:10:16
這是一個資產管理系統。每個資產都有10萬多件設備。每個資產也有一些與之相關的項目。每個項目對資產中的每件設備都有一個1k +項目的層次結構。計算是針對一個項目運行的，需要設備（100k +項目）加上項目中每個項目的所有數據。 – Colin 2015-03-19 13:05:15