Eric Evans在 2000 年代初撰写领域驱动设计 (DDD) 一书的原因是为了鼓励那个时代更好的领域驱动设计 (ddd) 实践。设计由数据模型驱动，技术和业务同事之间的协作不足。DDD 这本书反映了 Eric 当时的观点和观点，即他如何将软件开发世界推向更多领域驱动而不是数据模型驱动。他使用有界上下文、无处不在的语言和聚合等名称来真正强调这些信念。
这些是Domain-Driven Design (DDD)，而不是domain-driven design (ddd) ；
Mathias Verraes对 DDD的定义是思考什么是domain-driven design (ddd) 的起点：
DDD 是一门 [软件] 设计学科，您可以在其中 |
如果您考虑一下，这几乎适用于所有软件开发项目。我们都在不同程度上做所有这些事情。就像编写单元测试是一项技能一样，ddd 也是一项我们应该努力并努力提高的技能。
我个人将 domain-driven design (ddd) 定义为：
- 识别域中未满足的用户需求
- 获得该领域的专业知识
- 设计新功能以满足未满足的需求
- 为新功能的每个部分创建专门的模型
- 根据领域术语为每个模型建立专门的语言
- 在代码中实现模型
您可以在没有协作、进化和专注于战略领域的情况下进行 ddd，但除非你一个人工作，否则它不会有效。
Mathias 还添加了另一个关于 ddd 和 DDD 规模级别的精彩观点：
它从微观层面的代码和设计模式，到模型及其语言，到模型之间的通信和关系，再到对系统系统的大规模推理来考虑设计。 |
DDD与ddd区分的意义？
首先，我认为 DDD 不应与 ddd 分开或以任何方式放弃。对于初学者来说，它是一个很好的工具包，提供了开始使用 ddd 的指南和构建块，并有助于培养 ddd 思维方式。我也认为 DDD 对于想要接受它的有经验的团队来说是一个不错的选择。
但是，我确实认为我们应该能够在不暗示 DDD 的情况下谈论 ddd。我们可以谈论“做 ddd”，而无需使用 Bounded Context、Ubiquitous Language 和 Aggregate 等DDD专业术语。
更进一步，我认为应该有空间让其他固执的 ddd 哲学与 DDD 并存，例如Uber的面向领域的微服务。
我相信 DDD 社区应该接受所有形式的 ddd。我们可以尊重 DDD 的传统，同时仍然允许激进的新想法并包容不熟悉 DDD 的人。公平地说，DDD/ddd 社区已经很棒并且正在做这些事情。
作者：Nick Tune，技术负责人 | 社会技术架构师 | 持续交付| 组织设计