域驱动设计是开发复杂系统的方法和过程处方，其重点是将问题域内的活动，任务，事件和数据映射到解决方案域的技术工件中。
域驱动设计的重点是理解问题域，以便创建问题域的抽象模型，然后可以在一组特定的技术中实现该模型。域驱动设计作为一种方法论，为模型开发和技术开发如何产生一个满足使用它的人们需求的系统提供了指导，同时在面对问题领域的变化时也很健壮。
域驱动设计的过程端涉及领域专家（了解问题领域的人员）与设计/体系结构专家（了解解决方案领域的人员）之间的协作。这个想法是要使用一种共享的语言共享模型，以便当来自这两个不同领域的人们以两种不同的观点讨论解决方案时，他们实际上是在讨论具有共享概念的共享知识库。
需要特定系统的人员与正在设计和实施该系统的人员之间缺乏对问题域的共同理解，这似乎是成功项目的核心障碍。域驱动设计是解决此障碍的一种方法。
它不仅仅是拥有对象模型。重点实际上是关于共享通信和改善协作，以便可以发现问题域内的实际需求，并创建满足这些需求的适当解决方案。
域驱动的设计：优点和挑战提供以下内容的简要概述：
DDD可帮助发现顶层体系结构，并提供有关软件需要复制的域的机制和动态信息。具体来说，这意味着精心设计的DDD分析可以最大程度地减少领域专家和软件架构师之间的误解，并减少随后的昂贵变更请求数量。通过在较小的上下文中划分域复杂度，DDD避免了迫使项目架构师设计design肿的对象模型，在这种情况下，制定实施细节会浪费大量时间，部分原因是要处理的实体数量通常会超出会议室白板的大小。
另请参阅本文的服务结构域驱动设计，其中提供了一个简短示例。本文提供了以下域驱动设计的缩略图描述。
域驱动设计提倡基于与我们的用例相关的业务现实进行建模。随着它变得越来越老和炒作水平的降低，我们很多人都忘记了DDD方法确实有助于理解眼前的问题，并朝着对解决方案的共同理解设计软件。在构建应用程序时，DDD会讨论域和子域等问题。它以边界上下文的形式描述问题的独立步骤/区域，强调谈论这些问题的通用语言，并添加了许多技术概念，例如实体，值对象和聚合根规则以支持实现。
Martin Fowler写了许多文章，其中提到了域驱动设计作为一种方法。例如，本文BoundedContext概述了域驱动开发中的受限上下文概念。
在早期，我们被建议建立整个业务的统一模型，但是DDD意识到我们已经了解到“将大型系统的域模型完全统一是不可行或不具有成本效益的” 1。因此，DDD而是将大型系统划分为有界上下文，每个有界上下文可以具有统一的模型-本质上是构造MultipleCanonicalModels的一种方式。