我們如何從DDD中受益？ 第二部分| Shinetech軟體

banq發表於2018-11-09

“做正確的事;做正確的事”在我腦海中有機地出現。簡單的CRUD專案變得越來越不能勝任，程式設計師的速度很難提升，他們的工資也很難提升。我急於解決這個問題。然後有一天我看到了這樣一句話：我選擇做一件事不是因為它很簡單，而是因為它很難。我對這些話很有動力，我不能停止思考“簡單”“複雜”的“麻煩”。然後我想出了我需要做的事情：
1.做正確的事
2.做正確的事
做難事

然後我開始在網際網路上搜尋“複雜”“軟體”等關鍵詞，一本名為“領域驅動設計”的書吸引了我的眼球。我很久以前就聽說過Domain-Driven Design，對我來說真正有吸引力的是小標題 - “解決軟體核心的複雜性”。我不得不說，在我仔細閱讀本書之後，書中提到的戰略設計確切地提供瞭解決複雜業務的解決方案：無處不在的語言，有界上下文，設計是程式碼，程式碼是設計等等。我相信這是解決的邏輯艱難的事情，做正確的事情。那麼當你粗略地瞭解這個策略時，如何實現呢？在本書出版之前，我無法提供一個合適的例子來幫助我的同事使用領域驅動設計 - “實現域驅動設計”，

當你得到兩個“聖盃” - “領域驅動設計”和“實施領域驅動設計”時，就像你從美女那裡得到了一個聯絡資訊並知道她的家庭住址，但是從日出到現在還有一段距離。兩個人之間真實日期的日落。沒有在真正的專案中練習，只能理解邏輯就像在岸上游泳一樣。雖然我們已經在某些專案中使用了Domain的一些概念，但我們應該知道基於Database Driven應用DDD很困難。就在那時，我們從“財富”全球500強客戶那裡獲得了一個專案，他們的架構師被指定使用DDD，這讓我非常興奮，因為它讓我們有機會在複雜的業務中練習DDD。

就像“實現領域驅動設計”所說，Domain-Driven主要有兩個部分 - 戰略設計和戰術設計。

戰略設計（做正確的事）
無處不在的語言
域驅動開發讓域專家和開發人員將業務結合在一起，最有效的溝通方式是使用無處不在的語言。我們在這個專案的開頭定義了很多詞彙表，這是我們無處不在的語言。

有界上下文和域
當我們得到無處不在的語言和詞彙表時，每個詞彙都應該有自己的有界上下文，因為它在不同的有界上下文中有不同的含義。例如，你家裡的情人的有界背景是“你的妻子”，如果她是一名教師，那麼她在學校的有限語境就是“老師”。我們多次討論過如何定義邊界，我們採用了這種方法：將它劃分為多個子系統（Bounded Context看起來與微服務類似嗎？）每個子系統都有自己的自治權。
稍後我們將業務抽象為域模型，每個域都有自己的自治權。模型中的屬性和行為表示式是域專家可以理解的程式碼，例如，使用 Job. Publish().。雖然它最終產生了聚合根，實體和值物件等，但在與域專家溝通時我們應該避免使用這些詞彙表。我們可以用另一種方式表達它，例如：在招聘時，該職位是否必須由公司管理？然後我們就會知道Job屬於公司Aggregate root。使用統一語言構建模型（使用自然語言命名類名稱和方法名稱），領域專家將能夠直接閱讀並理解我們的程式碼，並知道它是否表達了業務需求。

戰術設計（做正確的事）
在戰術設計方面，由於業務行為和規則都屬於領域而系統被劃分為多個子系統，因此給技術實施帶來了巨大挑戰，尤其是我們大多數人都有一個基於資料驅動開發。從技術上講，有不同的實施方式，但我們從一開始就選擇了“最佳實踐”（實施域驅動設計），也就是說，我們使用了事件源和CQRS，這也是一種前進的難點。

事件溯源
事件溯源意味著我們不記錄資料的最終狀態，我們記錄事件（資料的每次更改），然後我們將透過在讀取資料時重新開始獲取資料狀態。例如，當您的銀行賬戶中有一百美元，而且只剩下10美元時，記錄的內容不會是“money.total = 10”，而是記錄您提取現金的每條記錄並重播您退出的過程。 100美元，那麼你將獲得10美元。
在我們編寫Event Sourcing時，我們通常會回想起Data-Driven的好處，我們認為在系統複雜性不斷增加之前使用事件採購非常煩人，我們發現使用Event Sourcing有很大的好處。我稍後會獨立談論它。

CQRS
當使用事件源時，做資料查詢真的很煩人，尤其是跨業務（聚合）查詢，在查詢中沒有像關係資料那樣的優勢。CQRS是解決這個問題的好方法。CQRS分離查詢和寫入，它寫入需要以其原始形狀查詢的介面資料，這意味著它預先正確地記錄介面，與其顯示方式相同，這與原始快取類似，沒有額外的連線操作，這是非常有效的查詢方式。
 

相關文章