貧血領域模型乙個明顯的特徵是：它僅僅是看上去和領域模型一樣，都是物件，都以領域空間中定
義的名詞命名，這些物件通過實際領域模型中豐富的關係和結構相互關聯。但是觀察模型所持有的
業務邏輯時會發現，貧血模型中除了大量 getter 和 setter，幾乎沒有其他業務邏輯。
當然，在使用貧血領域模型時，那些資料模型會從一系列服務物件（傳統上稱為業務層）中使用，這些
服務物件會捕獲所有領域或業務邏輯。業務層位於資料模型層之上，並僅將資料模型作為資料使用。
貧血領域模型只是一種過程化的風格設計。因為缺乏行為（方法），貧血實體物件不是真正的物件。它
們只有資料屬性，因此也不是物件導向的設計。通過將所有行為放到服務物件（業務層）中，最終得到
的是麵條式**或事務性指令碼，因此失去了領域模型提供的優勢。
無論如何，如果微服務或限界上下文非常簡單（如 crud 服務），使用表現為只有資料屬性的實體對
象的貧血領域模型或許足夠了，此時可能不值得實現更複雜的 ddd 模式。這種情況下，它將是乙個簡
單的持久化模型，因為已經有意為 crud 這個目標建立了只有資料的實體。
因此微服務架構完美適用於依賴每個限界上下文的多重架構方法。例如在 eshopooncontainers 中，訂
單微服務實現了 ddd 模式，但簡單的 crud 服務，如目錄微服務就沒有用到。
有人說貧血領域模型是乙個反模式。這其實取決於要實現什麼。如果正在建立的微服務足夠簡單（如
crud 服務），遵循貧血領域模型就不是反模式。但如果要應對微服務的領域有很多不斷變化的業務規
則並且很複雜，貧血領域模型對這樣的微服務或限界上下文可能就是乙個反模式。這種情況下，將其設
計為包含資料和行為以及實現額外的 ddd 模式（聚合，值物件等等）的富模型，或許對微服務的長期
成功有更大好處。
DDD領域驅動設計 充血模型 貧血領域模型
最早廣泛應用源於ejb2，最強盛時期則是由spring創造，把 分離到不同的物件中 貧血領域模型是乙個存在已久的反模式，它不是個好東西。它完全和物件導向設計背道而馳。物件導向設計主張將資料和行為繫結在一起，而貧血領域模型則更像是一種面向過程設計。貧血領域模型的根本問題在於，它引入了領域模型設計的所有...
領域模型 貧血模型 充血模型概念總結
領域模型 領域模型是對領域內的概念類或現實世界中物件的視覺化表示。又稱概念模型 領域物件模型 分析物件模型。它專注於分析問題領域本身，發掘重要的業務領域概念，並建立業務領域概念之間的關係。業務物件模型 也叫領域模型 domain model 是描述業務用例實現的物件模型。它是對業務角色和業務實體之間...
領域模型 貧血模型 充血模型概念總結
領域模型 領域模型是對領域內的概念類或現實世界中物件的視覺化表示。又稱概念模型 領域物件模型 分析物件模型。它專注於分析問題領域本身，發掘重要的業務領域概念，並建立業務領域概念之間的關係。業務物件模型 也叫領域模型 domain model 是描述業務用例實現的物件模型。它是對業務角色和業務實體之間...