在進行領域驅動設計時要避免的十個常見錯誤

Daniel Whittaker 在最近的一篇帖子中表示：在進行 領域驅動設計 （DDD）時，缺乏與領域專家的互動是一種常見的錯誤，而如果能夠盡早發現并解決這一問題，或許能夠避免團隊無謂的時間浪費。在這篇帖子中，Daniel共列舉了十種他發現開發者經常會犯的錯誤。

讓持久化或數據存儲問題影響模型的設計。 通過使用 戰術模式 ，例如聚合根，能夠簡化模型，并將相關概念與對基礎設施的關注面相互分離，例如數據存儲等等。如果在沒有經過與領域專家進行交流的前提下貿然開始數據架構或數據模型的設計，可能會導致所創建的代碼是基于某個關系型模型，而不是基于某個領域模型的。而在類似話題上， Stefan Tilkov 也在先前的一篇文章中對于在企業中使用標準化數據模型的方式提出了警告，這種方式可能會導致模型中充滿了可選的特性以及奇怪的行為。

缺乏與領域專家的交流。 DDD的核心實踐之一就在于通過與領域專家進行交談，從而以他們的角度對于問題領域進行理解。而 行為驅動開發 （BDD）實踐則強調與領域專家通過對話的方式創建行為的實例。對此， Konstantin Kudryashov 曾專門寫過一篇如何將BDD與DDD實踐相結合的文章。

忽視領域專家的語言。 DDD的另一個核心實踐在于創建一套通用語言，并與領域專家共享。這套通用語言必須使用在討論過程中，同樣也必須反映在代碼中，例如類與方法的名稱。

沒有鑒別出邊界上下文。 解決復雜問題的常見方式是將其分解為多個小問題。而 邊界上下文 就是為了將一個大的領域分解為多個小的子領域而出現的，每個邊界上下文將負責處理領域中的一個內聚的功能。這一點同樣也是 微服務 的核心概念，在今年的 DDD Exchange 大會的 主題演講 中，Eric Evans專門對此展開了討論。

使用貧血模型。 這是一個說明團隊并沒有正確地使用DDD的信號，也暗示著建模過程的失敗。一個 貧血模型 第一眼看上去與真正的領域模型非常相像，例如它們同樣使用了正確的名稱。但問題在于貧血模型中的類幾乎丟失了所有的行為，而變成了只包含單純的getter與setter屬性的容器。

Whittaker所認識到的另外五種常見的錯誤在于：

• 沒有讓邊界上下文隨著對領域的見解加深而相應地作出改變。
• 將所有邏輯都設想為領域邏輯。
• 過度使用集成測試。
• 將安全性視為領域的一部分（除非你本身設計的就是一種安全性領域）。
• 過度關注基礎設施。

Whittaker最提到的最后一個錯誤則是忽視了 事件風暴 的作用，這是由 Alberto Brandolini 所創建的一種專注于事件的設計過程。Brandolini的想法是，通過將所有的項目干系人都集中在一個房間內，為他們提供無限的空間進行建模工作，并讓他們用貼紙的方式寫出所有的領域事件。這種方式在幾個小時之內就能夠為某個問題領域創建出一套非常出色的模型。

查看英文原文： 10 Common DDD Mistakes to Avoid