领域驱动设计 （英語：domain-driven design ，缩写 DDD ）是軟體程式碼的結構及語言（類別名稱、類別方法、類別變數）需符合業務領域
领域驱动设计可以將實現 對應到持续进化的模型[ 1]
领域驱动设计的前提是：
把项目的主要重点放在核心領域 （core domain）和领域逻辑
以領域中的模型為基礎，進行复杂的设计
讓技術人員以及领域专家 该词是由埃里克・埃文斯（Eric Evans）在其同名书中创造。[ 2]
模型中有以下概念：
上下文（Context）
情境、脈絡、上下文。比如：電子商務系統。
領域（Domain）
知識，影響，或活動。客戶使用軟件要處理旳問題種類即為軟件的領域。
模型（Model）
一類描述域的不同方面並可用於解決相關問題的系統化的抽象。
通用語言（Ubiquitous Language）
一種領域專家使用，為了描述域模型 而構造的語言，以減少溝通成本。
理想情况下，只有一个统一的模型。 但是通常情况下都无法实现，因此在实践中通常分成多个模型。 认识这个事实并遵守它对实践是非常有益的。
策略设计的目的是设计一套原则用于是维护模型完整性，提升领域模型和使用多个模型。
任何大型项目都有多个模型。 然而，当基于不同模型的代码相结合，软件变得越来越多，不可靠，并且难以理解。 团队成员之间的交流变得越来越难。 模型的使用情境变得越来越不清晰。
因此：需要明确定义模型适用的上下文，并且根据团队组织，应用程序特定部分的使用情况以及代码库和数据库模式等物理表现明确设置边界。 保持模型在这些范围内严格一致，并且不被外部的问题影响。
持续集成 （continuous integration）当愈多人在相同的有限背景下工作时，模型就愈应该分裂。 团队越大，问题就越大，即使只有三四个人也会遇到严重的问题。 然而，将系统分解为更小的环境最终会失去一个有价值的整合和一致性。
因此：建立一个经常合并所有代码和其他实现工件的过程，用自动化测试快速标记碎片。通过持续地运用统一术语去夯实随着概念在不同人的头脑中的演变而逐渐形成对模型的共同观点。
在缺乏全局认识的情况下，个别有界上下文会留下一些问题。 其他模型的背景可能仍然是模糊不清的。
其他团队的人不会意识到上下文的界限，并且会不知不觉地做出模糊边缘或使连接复杂化的变化。 当连接必须在不同的上下文之间进行时，它们往往会相互渗透。
因此：确定项目中正在使用的每个模型并定义其有界的上下文。 这包括非面向对象子系统的隐式模型。 命名每个有界的上下文，并将其命名为通用语言的一部分。 描述模型之间的关联点，确保任何用于共享交流的词语都有清晰明确的含义。 映射现有的情形。
在领域驱动设计 一书中[ 2]
Entity
一个不由自身属性定义而是由标识线和它的身份定义的对象
例如：大多数航空公司在每次航班上都独特地区分每个座位。每个席位都是在这种情况下的一个实体。不过，西南航空，EasyJet 和瑞安航空并没有区分每个座位；所有的座位都是一样的。在这种情况下，一个席位实际上是一个Value Object Value Object
只包含元素属性的不可变对象
例如：当人们交换名片时，他们一般不会区分每张独特的名片；他们只关心印在卡片上的信息。在这种情况下，名片是 Value Object Service
强调与其他对象的关系，只定义了可以为客户做什么，不应该替代 Entity 和 Value Object 的所有行为 Module
一种表达机制，划分代码和概念 Factory
对于那些需要创建特定域对象的方法应该委派给工厂对象，因为这样可以更容易的替换实现 Repository
对于检索特定域对象的方法应该委派给 Repository 对象，因为这样可以很容易地互换替代存储的实现 Aggregate
由 ROOT ENTITY 绑定在一起的对象的集合，也称为聚合根。聚合根通过禁止外部对象保持对其成员的引用来保证在聚合内进行的更改的一致性
例如：驾驶汽车时，不必思考如何讓車輪前進，如何點燃引擎等。你只需要正常的使用。在这种情况下，汽车是其他几个对象的集合，并作为所有其他系统的聚合根 Domain Event
一个域对象定义了一个事件。域事件是域专家所关心的事件
为了帮助保证模型能作为一个单纯并有用的语言结构，团队通常必须在领域模型中实现大量的隔离和封装。因此，基于领域驱动设计的系统可能会花费相对较高的成本。虽然域驱动设计提供了许多技术优势，如可维护性，但 Microsoft 建议仅将它应用于复杂领域中，在这些复杂领域中，通过模型和语言处理能够在复杂信息中提供交流便利性的，并且能够该领域达成共识。[ 3]
采用 DDD 并不依赖于特定的工具。然而，也有许多开源的工具和框架可用，包括：
