Loading AI tools
来自维基百科,自由的百科全书
領域驅動設計(英語:domain-driven design,縮寫 DDD)是軟體程式碼的結構及語言(類別名稱、類別方法、類別變數)需符合業務領域中的習慣用法。例如處理租賃業務的軟體,其型別可以命名為LoanApplication及Customer,其方法可以用AcceptOffer及Withdraw。
此條目需要補充更多來源。 (2020年3月23日) |
領域驅動設計的前提是:
該詞是由埃里克・埃文斯(Eric Evans)在其同名書中創造。[2]
模型中有以下概念:
此條目翻譯品質不佳,原文在en:Domain-driven design。 |
理想情況下,只有一個統一的模型。 但是通常情況下都無法實現,因此在實踐中通常分成多個模型。 認識這個事實並遵守它對實踐是非常有益的。 策略設計的目的是設計一套原則用於是維護模型完整性,提升領域模型和使用多個模型。
任何大型專案都有多個模型。 然而,當基於不同模型的代碼相結合,軟體變得越來越多,不可靠,並且難以理解。 團隊成員之間的交流變得越來越難。 模型的使用情境變得越來越不清晰。
因此:需要明確定義模型適用的上下文,並且根據團隊組織,應用程式特定部分的使用情況以及代碼庫和資料庫模式等物理表現明確設定邊界。 保持模型在這些範圍內嚴格一致,並且不被外部的問題影響。
當愈多人在相同的有限背景下工作時,模型就愈應該分裂。 團隊越大,問題就越大,即使只有三四個人也會遇到嚴重的問題。 然而,將系統分解為更小的環境最終會失去一個有價值的整合和一致性。
因此:建立一個經常合併所有代碼和其他實現工件的過程,用自動化測試快速標記碎片。通過持續地運用統一術語去夯實隨著概念在不同人的頭腦中的演變而逐漸形成對模型的共同觀點。
在缺乏全域認識的情況下,個別有界上下文會留下一些問題。 其他模型的背景可能仍然是模糊不清的。 其他團隊的人不會意識到上下文的界限,並且會不知不覺地做出模糊邊緣或使連接複雜化的變化。 當連接必須在不同的上下文之間進行時,它們往往會相互滲透。
因此:確定專案中正在使用的每個模型並定義其有界的上下文。 這包括非物件導向子系統的隱式模型。 命名每個有界的上下文,並將其命名為通用語言的一部分。 描述模型之間的關聯點,確保任何用於共享交流的詞語都有清晰明確的含義。 對映現有的情形。
在領域驅動設計一書中[2]闡述了一些高層次的概念和實踐,比如通用語言,這意味著領域模型應該形成領域專家為描述系統需求而提供的共同語言,同樣的,這些語言也需要能夠被商業使用者或贊助商和軟體開發商使用。本書專注於將領域層描述為具有多層體系結構的物件導向系統中的常見層次之一。在 DDD 中,有表示,建立和檢索域模型的工件:
為了幫助保證模型能作為一個單純並有用的語言結構,團隊通常必須在領域模型中實現大量的隔離和封裝。因此,基於領域驅動設計的系統可能會花費相對較高的成本。雖然域驅動設計提供了許多技術優勢,如可維護性,但 Microsoft 建議僅將它應用於複雜領域中,在這些複雜領域中,通過模型和語言處理能夠在複雜資訊中提供交流便利性的,並且能夠該領域達成共識。[3]
採用 DDD 並不依賴於特定的工具。然而,也有許多開源的工具和框架可用,包括:
Seamless Wikipedia browsing. On steroids.
Every time you click a link to Wikipedia, Wiktionary or Wikiquote in your browser's search results, it will show the modern Wikiwand interface.
Wikiwand extension is a five stars, simple, with minimum permission required to keep your browsing private, safe and transparent.