概念
模型中有以下概念:
戰略
理想情況下,只有一個統一的模型。 但是通常情況下都無法實現,因此在實踐中通常分成多個模型。 認識這個事實並並且準守它對實踐是非常有益的。 策略設計的目的是設計一套原則用於是維護模型完整性,提升領域模型和使用多個模型。
界限上下文(bounded context)
任何大型項目都有多個模型。 然而,當基於不同模型的代碼相結合,軟體變得越來越多,不可靠,並且難以理解。 團隊成員之間的交流變得越來越難。 模型的使用情境變得越來越不清晰。
因此:需要明確定義模型適用的上下文,並且根據團隊組織,應用程式特定部分的使用情況以及代碼庫和資料庫模式等物理表現明確設定邊界。 保持模型在這些範圍內嚴格一致,並且不被外部的問題影響。
持續集成(continuous integration)
當愈多人在相同的有限背景下工作時,模型就愈應該分裂。 團隊越大,問題就越大,即使只有三四個人也會遇到嚴重的問題。 然而,將系統分解為更小的環境最終會失去一個有價值的集成和一致性。
因此:創建一個經常合併所有代碼和其他實現工件的過程,用自動化測試快速標記碎片。通過持續地運用通用語言去夯實隨著概念在不同人的頭腦中的演變而逐漸形成對模型的共同觀點。
上下文地圖(context map)
在缺乏全局認識的情況下,個別有界上下文會留下一些問題。 其他模型的背景可能仍然是模糊不清的。 其他團隊的人不會意識到上下文的界限,並且會不知不覺地做出模糊邊緣或使連線複雜化的變化。 當連線必須在不同的上下文之間進行時,它們往往會相互滲透。
因此:確定項目中正在使用的每個模型並定義其有界的上下文。 這包括非面向對象子系統的隱式模型。 命名每個有界的上下文,並將其命名為通用語言的一部分。 描述模型之間的關聯點,確保任何用於共享交流的詞語都有清晰明確的含義。 映射現有的情形。
基礎
在領域驅動設計一書中闡述了一些高層次的概念和實踐,比如通用語言,這意味著領域模型應該形成領域專家為描述系統需求而提供的共同語言,同樣的,著這些語言也需要能夠被商業用戶或贊助商和軟體開發商使用。本書專注於將領域層描述為具有多層體系結構的面向對象系統中的常見層次之一。在 DDD 中,有表示,創建和檢索域模型的工件:
Entity
一個不由自身屬性定義而是由標識線和它的身份定義的對象
例如:大多數航空公司在每次航班上都獨特地區分每個座位。每個席位都是在這種情況下的一個實體。不過,西南航空,EasyJet 和瑞安航空並沒有區分每個座位;所有的座位都是一樣的。在這種情況下,一個席位實際上是一個價值對象。
Value Object
只包含元素屬性的不可變對象
例如:當人們交換名片時,他們一般不會區分每張獨特的名片;他們只關心印在卡片上的信息。在這種情況下,名片是 Value Object。
Service
強調與其他對象的關係,只定義了可以為客戶做什麼,不應該替代 ENTITY 和 VALUE OBJECT 的所有行為。
Module
一種表達機制,劃分代碼和概念。
Factory
對於那些需要創建特定域對象的方法應該委派給工廠對象,因為這樣可以更容易的替換實現。
Repository
對於檢索特定域對象的方法應該委派給 Repository 對象,因為這樣可以很容易地互換替代存儲的實現。
Aggregate
由 ROOT ENTITY 綁定在一起的對象的集合,也稱為聚合根。聚合根通過禁止外部對象保持對其成員的引用來保證在聚合內進行的更改的一致性
例如:駕駛汽車時,不必擔心向前移動車輪,使發動機燃燒火花和燃料等。你只是在開車。在這種情況下,汽車是其他幾個對象的集合,並作為所有其他系統的聚合根。
Domain Event
一個域對象定義了一個事件。域事件是域專家所關心的事件。
局限
為了幫助保證模型能作為一個單純並有用的語言結構,團隊通常必須在領域模型中實現大量的隔離和封裝。因此,基於領域驅動設計的系統可能會花費相對較高的成本。雖然域驅動設計提供了許多技術優勢,如可維護性,但 Microsoft 建議僅將它套用於複雜領域中,在這些複雜領域中,通過模型和語言處理能夠在複雜信息中提供交流便利性的,並且能夠該領域達成共識。