优点

DDD，或领域驱动设计，是一种架构开发方法，专注于创建一个领域特定的模型，以解释软件系统的各个组成部分。它基于将领域模型与应用模型分离的原则，并专注于软件所要服务的核心领域。这种方法使开发人员能够创建更易于维护和可扩展的软件，同时提供强大的功能集。通过专注于领域特定的模型，开发人员可以确保他们的软件更加高效，更适合特定的用例。
当明智地完成时，它是关于采用工匠般的方法来构建软件，并认识到需要减少开发团队与为其构建软件的业务之间的认知摩擦。最重要的实践之一是在软件团队和业务团队使用的域词汇尽可能匹配的层次。您可以在理解要解决的业务问题的过程中迭代构建此层次。当业务逻辑明智地编码在此层次中，与企业应用程序通常具有的复杂依赖关系隔离，将与这些系统的交互抽象到接口，实际域层次中使用的语言最终变得相当简洁，明显和可读。当您与业务团队审查模型时，他们通常会纠正您，您逐渐重构以获得对域的更深入理解。
DDD承认系统很少孤立存在。DDD包括面向遗留系统的应对模式（反腐败层，有界上下文等）。

构成

• 应用层{application}
  • 应用服务位于应用层。用来表述应用和用户行为，负责服务的组合、编排和转发，负责处理业务用例的执行顺序以及结果的拼装。
  • 应用层的服务包括应用服务和领域事件相关服务。
  • 应用服务可对微服务内的领域服务以及微服务外的应用服务进行组合和编排，或者对基础层如文件、缓存等数据直接操作形成应用服务，对外提供粗粒度的服务。
  • 领域事件服务包括两类：领域事件的发布和订阅。通过事件总线和消息队列实现异步数据传输，实现微服务之间的解耦。
• 领域层{domain}
  • 领域服务位于领域层，为完成领域中跨实体或值对象的操作转换而封装的服务，领域服务以与实体和值对象相同的方式参与实施过程。
  • 领域服务对同一个实体的一个或多个方法进行组合和封装，或对多个不同实体的操作进行组合或编排，对外暴露成领域服务。领域服务封装了核心的业务逻辑。实体自身的行为在实体类内部实现，向上封装成领域服务暴露。
  • 为隐藏领域层的业务逻辑实现，所有领域方法和服务等均须通过领域服务对外暴露。
  • 为实现微服务内聚合之间的解耦，原则上禁止跨聚合的领域服务调用和跨聚合的数据相互关联。
• 基础层{infrastructure}
  • 基础服务位于基础层。为各层提供资源服务（如数据库、缓存等），实现各层的解耦，降低外部资源变化对业务逻辑的影响。
  • 基础服务主要为仓储服务，通过依赖反转的方式为各层提供基础资源服务，领域服务和应用服务调用仓储服务接口，利用仓储实现持久化数据对象或直接访问基础资源。
• 接口层{interfaces}
  • 接口服务位于用户接口层，用于处理用户发送的Restful请求和解析用户输入的配置文件等，并将信息传递给应用层。

应用

DDD的核心诉求就是将业务架构映射到系统架构上，在响应业务变化调整业务架构时，也随之变化系统架构。而微服务追求业务层面的复用，设计出来的系统架构和业务一致；在技术架构上则系统模块之间充分解耦，可以自由地选择合适的技术架构，去中心化地治理技术和数据。

• 业务架构——根据业务需求设计业务模块及其关系
• 系统架构——设计系统和子系统的模块
• 技术架构——决定采用的技术及框架

设计领域模型的一般步骤如下

1. 根据需求划分出初步的领域和限界上下文，以及上下文之间的关系；
2. 进一步分析每个上下文内部，识别出哪些是实体，哪些是值对象；
3. 对实体、值对象进行关联和聚合，划分出聚合的范畴和聚合根；
4. 为聚合根设计仓储，并思考实体或值对象的创建方式；
5. 在工程中实践领域模型，并在实践中检验模型的合理性，倒推模型中不足的地方并重构。