|
在看到CQRS架構之后覺得很有道理，但是有以下幾點疑問 1.CQRS架構圖中的在發(fā)生一個Command之后肯定會有一個Command Handle來做處理，并且Command這是滿足并針對自身的，但是后面又看到了Command Handle來調用Domain,并且Domain在調用Repository，疑問就出現(xiàn)在這里了，為什么Handle要去調用Domain，還有就是Repository是否要注入到Domain中，還是說可以使用Event來調用Repository. 2.看CQRS架構中出現(xiàn)了Snapeshot和Event Store，疑問是SnapeShot跟Event Store之間是否有關系存在，還有就是SnapeShot跟Event Store兩者區(qū)別在那里. 3.Banq老師說到了EJB推崇貧血模式，在CQRS架構在集群中是使用事件來做傳遞的，但是事件是有事件源的，事件在傳遞的過程中事件源不需要做傳遞么.還是將事件源存儲在某個中心服務器上面. 4.Banq老師說道ActiveRecord的致命缺陷是：當業(yè)務邏輯復雜到一定程度，它開始崩潰，業(yè)務邏輯很難維護，一致性保證很困難，更進一步說：實際上是關系數(shù)據(jù)庫掌管了業(yè)務狀態(tài)，關系數(shù)據(jù)庫成為單點風險和性能瓶頸，只能走數(shù)據(jù)庫sharding 等路線進行伸縮(本站有更多關于關系數(shù)據(jù)庫問題的文章)，這里業(yè)務邏輯復雜之后會很難維護本人不是很明白上述幾點問題，還請舉例說明. 對于以上幾點問題還請大家詳細說明，謝謝！ --------------------------------------------------------------- 1,Commond到達它被處理的Handler，這通常是一對一，然后會觸發(fā)領域模型的交互，因為業(yè)務邏輯在Domain上，Domain的行為會生成領域事件，Domain沒有直接掉Repository，注意那張圖，Domain由Repoisitoy返回，Domain上的事件可能由Reposiotry發(fā)到事件總線。 2,Snapeshot是模型的快照，Event Store是存儲在Domain上的事件，舉個例子，一個人從出生就開始記錄在它身上發(fā)生的任何事情，然后讓他再出生的一次，同時把Event Store里事件回放一下就可以還原到它的現(xiàn)在?？上攵@個事件太多了，那么就在某個時候保存一個快照，比如在他18歲的時候，這樣就可以從18歲開始回放。 3,這個看你怎么設計，可以直接帶事件源對象或者帶ID，因為我們通常處理的是實體對象，用ID去Repository里取就可以了。Jdon框架帶的只是一個Object，隨便你放什么。 4,活動記錄，和關系數(shù)據(jù)庫綁得太死，那么問題就是關系數(shù)據(jù)庫的問題，多搜索一下。 希望對你幫助! [該貼被OOjdon于2010-12-18 19:57修改過] ---------------------------------------------------------------- 首先很感謝你的回答，確實幫助了我很多，但是還有有幾個問題 1.Handle主要做什么，還有Handle來驅動Domain觸發(fā)事件么 2.SnapeShot是模型的一個快照，我可以把它看做是一個帶有時間標識的緩存么，而Event Store是存儲歷次狀態(tài)事件的存儲點，由SnapeShot返回某個時間點的模型標識(ModelId)，在到Event Store去取出跟此次狀態(tài)有關的事件么 3.CQRS架構的讀寫分離，本人不是很明白讀如何進行分離，是否需要針對查詢來做專類的對象。但是如果使用查詢專類對象的話，那么Domain對查詢專類對象有用處，因為兩者還是有所區(qū)分的 ---------------------------------------------------------------- 1,Handler就是接受到命令然后讓領域模型做事情，這個Handler我認為在某些時候還可以省略，在JiveJdon中有直接把命令打到Domain上的代碼，領域模型在完成業(yè)務邏輯的時候會產(chǎn)生事件，比如貨物到達目的地會有deliver事件，商品有上架事件或被買走事件，領域事件由領域模型扔出來的，當然系統(tǒng)中還有各色各樣的事件。 2,事件回放產(chǎn)生完整Domain,DDD Factory也可以產(chǎn)生完整Domain,有完整Domain才會有緩存，至于怎么得到這個完整Domain,你可以事先直接把對象序列化，或者從數(shù)據(jù)庫中構造。 2010年12月18日 22:06 "spawnyy"的言論 由SnapeShot返回某個時間點的模型標識(ModelId) ... 注意，對象標識是不變的，和時間沒有關系。3,想象沒有數(shù)據(jù)庫，數(shù)據(jù)是領域對象交互完成業(yè)務邏輯時的產(chǎn)物，這個產(chǎn)物被異步到一個sql或者NoSQL DB保存，然后有人直接來這個DB查詢，你怎么查，怎么優(yōu)化，怎么加視圖，加緩存，怎么做DTO，怎么Match你的UI，是你的事，Domain已經(jīng)分析和開發(fā)完成，這就是讀寫分離。 這是我對CQRS的理解，大家一起討論吧。 [該貼被OOjdon于2010-12-19 11:10修改過] [該貼被OOjdon于2010-12-19 11:13修改過] ---------------------------------------------------------------- 我個人感覺也沒什么必要增加Handle，這里的Command就是命令只要發(fā)送到Domain受理就可以了，但是可能我理解的SnapeShot有點問題，這個快照是一個模型近期的快照呢，還是歷次的回放？還有就是Event Store每次存儲事件的時候可以把它看做是一個存儲器吧，不過存儲的方式是存儲事件呢還是事件源呢。對于讀寫分離，如何讀這塊需要根據(jù)自己需要去設計，而不是將Domain去為查詢去做些妥協(xié)的事情，對么？ [該貼被spawnyy于2010-12-19 11:47修改過] ---------------------------------------------------------------- Handler可以做權限等事情，所以是有必要的，保持Domain層的足夠內聚，DDD書中也還有應用層到領域層呢！ Domain對象可能就是一個不Match UI 和 DB的東西，我們現(xiàn)在不過是向兩邊妥協(xié)了,所以有Action幾千行，Service幾千行的代碼 Hibernate in Action書中的案例代碼，DDD sample 使用SSH的方式都不是這樣的。 對于cqrs,你可以研究下axon這個框架。該框架實現(xiàn)的快照是可配置的，做法是直接將對象序列化，比如配置你18歲，22歲序列，然后就不用回放你18歲之前，22歲之前。 [該貼被OOjdon于2010-12-19 12:16修改過] --------------------------------------------------------------- 2010年12月18日 19:45 "oojdon"的言論 Commond到達它被處理的Handler，這通常是一對一，然后會觸發(fā)領域模型的交互 ... 其實，這是我認為DDD中領域事件的局限性。在我看來，一個Commond可能會有多個handler，甚至還會有多個handler的編排，就像ESB里做的一樣。在復雜的業(yè)務場景里，一個對象的創(chuàng)建常常會導致多個對象的狀態(tài)發(fā)生變化，這還不包括倉儲層的響應。 |
|
|
來自： CevenCheng > 《DDD》
