發現“領域”話題

  之前一直想一些編程方面的歸類和聚合,沒想到這些東西其實早就被人討論。讀書少傷害大。

  可能跟自己的方向不一樣,不過“領域驅動“DDD,這個,確實在考慮怎麼把相關的類放在一起。在面向對象的基礎上進行另一層整合。這比普通的分層方便多了。

  之前想一個功能,當它再次出現的時候會想把它放到哪個地方合適,方便在下一次出現的時候直接引用。一般都有固定的層去容納這些功能,有的時候好像分到哪一層都可以又哪一層都不歸屬。有領域來打破普通的層界限的話會好一點,可能也只是提供了一種思考方式,下一步又徘徊在好像分到哪一個領域都可以好像又都不歸屬。

  

    圖裏說,命令查詢分離和時間溯源實現領域驅動。命令過來經過控制器進入命令隊列,然後被處理並儲藏到事件庫裏,同時更新用於顯示的view db。查詢的時候直接通過viewdb取或者通過事件庫對事件進行回溯,重新計算出來最終結果,以此作爲一種確認方法來處理重要嚴謹的數據查詢。

   其它部分不是很清楚。這裏很有趣的一點是,計算機處理了一種人的業務流程。大體就是,對重要事情進行確認的時候,會追溯排查變動歷史。本來機器更新已經能確定最終結視圖是正確的,可是對重要事件還是進行一次類似人的習慣,重新排查計算,根據歷史記錄。這樣可以增強一些確保同時減輕了更新viewDB處理時的嚴謹度。顯得程序好設計一些。 之前沒有想過有類似的做法,這種處理比較順應人的思考,對程序運轉和編程過程都有很好的幫助。

  領域的分話題有些多,主要的還是用來聚合一些功能方便更改和維護。圖中的領域視圖可能用來處理一些偏向銀行的特殊業務,使得事情的業務邏輯把框架影響成這幅特殊的樣子。一般一些其它場景可能不好理解它在做什麼,我就不是很理解。

  關於領域 查詢和命令分離這種做法,還是有些覺得有可以繼續優化的空間。或許讀書少的我沒有發現已經有這樣一些方法了,只不過換了個老夫沒聽到過的名詞。

  領域本來就是做相關功能的聚合,查詢也涉及到一些業務邏輯,也可以做成一些相關查詢的聚合。這些處理就像軟件裏有一個個部門,每個部門負責特殊的事情。或者說沒有軟件的話,這些事本來就是由一些相交互的部門,部門裏各種人員的職責任務,來完成。計算機取代了其中需要重複和計算的部分,業務的處理流程並不需要再次構思。順應本來應該有的人的思考過程就可以了,也就是對業務的處理、對待過程。之前只想過靠穩定的計算來直接分配任務到各個類,沒有想過計算也可以被設計成不穩定的,重要數據可以像現實中一樣通過再次覈算來確保。

  或許這也並不是什麼重要的功能,仍然會給人眼前一亮。

  查詢和業務分離不是那麼合適,查詢也是業務的一部分,也是由一個部門負責。這個部門爲了導出查詢數據需要從其它很多部門彙集數據。這個部門對彙集數據的處理 以及 對彙集過程中和各個部門的交互 都是它的固定業務。或者不同的查詢部門導出不同的數據,有不同的作用,和其它每個部門的交互方式也不同。

  如果是資源管理業務偏向的視角的話,把聚合體當作是一個部門會比較容易。

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章