这是来自drdobbs的Dino Esposito文章。在领域驱动设计提出后这十年，DDD已经证明对于某些复杂项目是有效的，为实践提供了适当的指导。
大约十年前，Eric Evans提出新的软件开发方法：领域驱动设计(DDD)，这是一本很受欢迎的书籍。
起初，DDD听起来像一个相当有前途的方法。对于一个复杂的项目开发人员来说非常诱人。在DDD中,一旦理解了软件需要解决的业务领域，那么你所要做的就是建立一个分层架构，业务逻辑被分成两个不同的模块,核心域逻辑(相对用例是不变的)和应用程序逻辑(用例)的实现。
DDD有其自身的分析部件(如通用语言,有界的上下文和上下文映射;它有一个战略组成部分方面用来严格支持相关软件架构和实现。流行的富领域模型(充血模型)只是许多可能的支持架构的其中之一。(一个基于充血领域模型的系统本质上并不比一个普通的CRUD系统更好，只要这两个系统满足需求。软件的复杂性主要源于基础业务的复杂性问题)。
DDD为理解错综复杂的业务领域提供了宝贵帮助。DDD提供的分析部分要好于其支持架构。DDD无处不在的语言提供一个方法来了解关键术语：名词、动词、副词——这些都是由业务专家使用。通过建立这样一个词汇，架构师和开发人员也可以理解它们。因为即使在同一家公司,语言会经常变化，使用相同的术语却意味着不同的东西或代表不同的聚合数据，这就造成沟通混乱。这种情况下形成一个最终系统的有界上下文，就像一个黑盒连接到系统的其余部分。上下文映射是连接上下文的映射图。每个环境都有自己的语言，使用一个独立的实现和接口与其他有界的上下文交互调用。整个系统就是由有界的上下文组成。DDD的最终目的是在有界的上下文中实现清晰而明确的收集需求。
DDD应对软件设计的复杂性不是作弊,。它将专注于问题域。然而,DDD却是很容易被做错，从而带来显著的成本。
普遍认为,虽然可以使用DDD带来明显的好处,但是却难以解释为什么需要实现这些好处。事实是，在过去的十年中,许多项目使用DDD有许多成功与失败。那些最终成功仍然经历了相当多的困难。为什么?
我的理解是,对DDD有一些误解，最重要的是,DDD往往减少到仅仅是建设项目中的一个领域模型。但也有一些其他的误解,比如将领域模型看成需要包含所有可能的行动，还有，将领域模型的构件(如通用语言)作为直接实现细节(抽象和具象不分)。
我叫他们为“误解”——从字面上,基于错误的观点或意见不正确的思考和理解。根据起点和上下文每个感知都可以是正确或错误。DDD的起点是它为设计服务的，然后才可能为落地实现细节的目的服务。所以,事实上,实现细节在哪里?
DDD有助于发现高层架构，发现软件需要复制的领域中的机制和动态。具体地说，它意味着一个好DDD分析会最小化减轻领域专家和软件架构师之间的误解，并且减少了后续昂贵的需求变化的数量。
通过分割复杂性领域到较小的上下文场景，DDD避免让项目架构师设计一个臃肿的对象模型，这个胖模型花费大量的无用时间在工作实现细节——部分原因是实体处理通常数量的增长超出了大小会议室的白板。（因为细节太多，超过会议讨论的范围，具体实现时会加入到对象模型中造成臃肿庞大的一个大对象，DDD目标是在会议讨论时将这些细节提前设计切分为上下文场景）
DDD针对特定类型的项目是一种有效的技术：复杂的项目通常有一个很大的问题域，需要与领域专家交流需求。使用一个模型直接落地为一个编程设计(一般来说,OO)实现，对于这些项目，这几乎是理想状态。然而。理解领域模型如何准确地映射到编程实现是至关重要的，这一步往往决定了项目的成败。