2012-11-04 69 views
2

只是審查我正在計劃,看看它是否可以工作。cqrs沒有事件採購和LMAX風格單線程設計審查

我正在使用RDBMS並計劃在沒有事件源的情況下使用CQRS。我認爲事件採購對於第一次嘗試有點高級,我不得不使用RDBMS。

基於任務的UI由許多命令組成,其中大多數命令不需要響應。

架構基本上是

  /---- RDBMS (EF) 
    IO ops     \ 
      |     \ 
    Single threaded Domains Fascade(DTO) Queries 
      |    /
    Event/Command Dispatcher/
      \   /
       MVC client 

單線程域不相互交談,他們通過干擾(基本上環形緩衝器)聊到了外面的世界。

命令調度程序將外部事件和命令複製到磁盤並在崩潰時重新加載它們。完成顯式標記(由IO Ops)。

命令基本上會被持久化(使用命令的事務範圍),IO Ops層將獲取所有事件並處理它們並在1個事務中標記命令完成。 (請注意,該命令通過日誌服務持續存在,而不是域,但它與IO opps進行通信,使其與命令的工作匹配)。如果命令失敗並且其標記持續(不是全部),則可以重播。 (它只在命令有命令並且已收到DoTransation消息時才持續執行命令。)

命令調度程序通過disruptor連接到域。

問題

  1. 我應該加載整個域到內存?(約300 - 500 MEG)和該運行顯然域只會數據庫更新後更新。

  2. 可以將外部事件重新混合到命令調度程序中(所以它會被單線程處理並處理)。例如事件變成命令。

  3. 看起來很簡單的代碼域和用戶代碼(我得到一個很好的豐富的域),至少從我正在工作的原型。是嗎?

  4. 當域做IO他們將消息發送到一個破壞者,並可以

    • 指定命令GUID和命令被匹配了一個 交易
    • 承擔完成(拍攝和祈禱)
    • 提供回調命令,將其傳遞給命令調度程序,然後再出現在域中。創建IO消息後,系統可以繼續使用當前命令或完成當前命令並接收下一個命令。
      這夠好嗎?
  5. 系統運行在一個進程和共享內存中,但域資源只能由自己和1個線程訪問。這個可以嗎?

這是一個實驗性的微米網格。有什麼想法嗎?

回答

3

首先,這個架構相當複雜。仔細檢查一下,項目的預計壽命是否值得在體系結構中進行初始投資。底線:這個項目是否會在5年或10年內支付賬單?客戶是否會允許您花費數月的時間在架構上而不提供業務價值?

問題

你沒有提到什麼承載您的命令調度。無論這件作品是什麼,它很可能是您的應用程序的瓶頸。除非它將消息從一個非常高性能的隊列中取出(例如ZeroMQ),否則我不認爲你需要一個環緩衝區。隊列在大多數情況下都會很好,而且更簡單。

您的問題

我假設IO行動意味着事件/事件處理程序。可能還有其他的細節我沒有抓到。

  1. 我懷疑這對web應用程序是否真的有意義。如果您的數據庫是性能瓶頸,那麼將該域載入內存是有益的。根據您的應用程序的性能配置文件,可能不會,並且管理所有這些線程的努力可能會浪費開發人員的時間。 (主要是因爲您必須確保在應用程序關閉時停止線程,否則應用程序將永遠不會關閉。)在更新數據庫之後更新域的部分對我來說沒有意義。您只想在啓動時加載域。保存域的狀態更改只能在下次啓動時重新加載。我認爲你需要改變域的狀態,然後才能堅持下去。另外,如果數據庫有那麼多瓶頸,我可能會異步保存狀態。

  2. 我想你錯過了這裏的一些步驟。您可能想要參加一個活動並將其作爲一個命令發送,聽起來就像流程管理器(或者,如果您喜歡佐賀)應該去的地方。很少有業務流程像總是將事件轉換爲命令一樣簡單。例如。後續命令無法完成時會發生什麼?或者在發佈命令之前需要發生多個事件。 (例如,OrderPlaced和PaymentReceived必須在發送ShipOrder之前發生)

  3. 域的難題通常是找出建模它們最合適的方法。如果您的域模型不適合實際的域,那麼代碼會變得更加尷尬和複雜。除此之外,這真的取決於你的域名。如果你編寫一個微積分求解器,你可能會爲此付出代價。但是,一旦理解,業務邏輯通常可以合理編好。

  4. 我真的不知道你想用交易位做什麼。你是否想將多個命令包裝到一個事務中?這可能表示域可以更好地建模,或者您正在進行批處理。因爲希望沒有那麼多命令被批量處理,似乎總是使用一個命令是浪費。如果您的所有操作都是批處理的,並且批處理中的每個操作都只是設置單個字段,那麼您確實錯過了使用DDD和基於任務的UI的要點。

  5. 另請參閱#1。如果需要這種級別的性能,這應該沒問題。您的域很可能會在接收命令的MVC應用程序中作爲單身存儲在內存中。我假設你在訪問共享內存時使用了正確的鎖定技術。請注意0​​是這些主題的一個很好的資源。特別是,不要被volatile關鍵字愚弄!

只記得一切都是取捨。不要浪費大量時間開發並不能真正爲您的應用帶來好處的架構。