领域驱动设计（，缩写 DDD）是軟體程式碼的結構及語言（類別名稱、類別方法、類別變數）需符合業務領域中的習慣用法。例如處理租賃業務的軟體，其型別可以命名為LoanApplication及Customer，其方法可以用AcceptOffer及Withdraw。
领域驱动设计可以將實現對應到持续进化的模型。
领域驱动设计的前提是：
- 把项目的主要重点放在核心領域（core domain）和领域逻辑
- 以領域中的模型為基礎，進行复杂的设计
- 讓技術人員以及合作，以迭代方式來完善特定领域问題的概念模型
该词是由埃里克・埃文斯（Eric Evans）在其同名书中创造。
概念
模型中有以下概念：
; 上下文（Context）
: 情境、脈絡、上下文。比如：電子商務系統。
; 領域（Domain）
: 知識，影響，或活動。客戶使用軟件要處理旳問題種類即為軟件的領域。
; 模型（Model）
: 一類描述域的不同方面並可用於解決相關問題的系統化的抽象。
; 通用語言（Ubiquitous Language）
: 一種領域專家使用，為了描述域模型而構造的語言，以減少溝通成本。
战略
理想情况下，只有一个统一的模型。 但是通常情况下都无法实现，因此在实践中通常分成多个模型。 认识这个事实并遵守它对实践是非常有益的。
策略设计的目的是设计一套原则用于是维护模型完整性，提升领域模型和使用多个模型。
界限上下文（bounded context）
任何大型项目都有多个模型。 然而，当基于不同模型的代码相结合，软件变得越来越多，不可靠，并且难以理解。 团队成员之间的交流变得越来越难。 模型的使用情境变得越来越不清晰。
因此：需要明确定义模型适用的上下文，并且根据团队组织，应用程序特定部分的使用情况以及代码库和数据库模式等物理表现明确设置边界。 保持模型在这些范围内严格一致，并且不被外部的问题影响。
持续集成（continuous integration）
当愈多人在相同的有限背景下工作时，模型就愈应该分裂。 团队越大，问题就越大，即使只有三四个人也会遇到严重的问题。 然而，将系统分解为更小的环境最终会失去一个有价值的整合和一致性。
因此：建立一个经常合并所有代码和其他实现工件的过程，用自动化测试快速标记碎片。通过持续地运用统一术语去夯实随着概念在不同人的头脑中的演变而逐渐形成对模型的共同观点。
上下文映射（context map）
在缺乏全局认识的情况下，个别有界上下文会留下一些问题。 其他模型的背景可能仍然是模糊不清的。
其他团队的人不会意识到上下文的界限，并且会不知不觉地做出模糊边缘或使连接复杂化的变化。 当连接必须在不同的上下文之间进行时，它们往往会相互渗透。
因此：确定项目中正在使用的每个模型并定义其有界的上下文。 这包括非面向对象子系统的隐式模型。 命名每个有界的上下文，并将其命名为通用语言的一部分。 描述模型之间的关联点，确保任何用于共享交流的词语都有清晰明确的含义。 映射现有的情形。
基础
在领域驱动设计一书中
与其它概念的关系
工具
采用 DDD 并不依赖于特定的工具。然而，也有许多开源的工具和框架可用，包括：
- Actifsource
- Apache Isis
- ECO (Domain Driven Design)
- OpenMDX
- OpenXava
- Restful Objects
- CubicWeb
- ENode
参见
- 定义域
- 事件風暴
- 知识表示
- 本体 (信息科学)
*
- 语义网络 (计算机科学)
- 语义学
参考文献
外部链接
- .
*
评论 (0)