DDD分层架构到底是个啥？

DDD分层架构是一种基于领域驱动设计（Domain Driven Design，DDD）思想的软件架构模式。

DDD全名为领域驱动设计，它代表的是一种高质量的软件开发方法，是一种开发复杂软件的系统化的方法学和思想。其核心特点包括：

• UL（Ubiquitous Language，通用语言）：指现实开发过程中，针对不同开发人员（如开发、测试、架构师）和不同业务人员（如产品经理、销售）等的一个共用的语言，作为项目团队沟通和协商形成的统一语言，方便大家协作和沟通交流。同时，限定了通用语言后，同样可以反应在代码中，在给领域对象命名的时候，则可以使用通用语言命名。
• BC（Bounded Context，限界上下文）：产生的原因在于，对于同一个单词或者句子的通用语言UL，在不同的环境下是可能会产生歧义的。所以需要给它划定上下文范围，防止产生歧义。

分层架构是将软件模块按照水平切分的方式分成多个层，一个系统由多层组成，每层由多个模块组成。它是一种代码的开发架构，是针对代码开发的。

最初的三层架构就是表现层（UI）、业务逻辑层（BLL，也称作领域层）、数据访问层（DAL），分别负责前端开发包括请求处理和返回、业务逻辑开发和底层数据库操作和数据保存。

DDD分层架构是在最初的三层架构进化扩展而来的。它是在假设系统高度复杂的情况下的一种设计思想，这种分层架构尽可能的对所有可能的情况进行了全面的考虑。它分为用户接口层、应用层、领域层、基础层。

• 用户接口层：负责前端开发和请求处理返回等，多了DTO（数据转换对象）来协助数据转换，将前端传过来的对象转换为后端需要的对象，DTO相当于原始三层架构中业务层的VO。
• 应用层：主要负责业务逻辑的整合组装转发，此外，还涉及其他微服务RPC调用（远程调用）、分布式事务实现、消息驱动事件的驱动、日志记录等。
• 领域层：负责处理更细的业务逻辑，包含实体、值对象、聚合、领域服务、仓储接口等领域对象内容。之前的数据访问层的PO、映射、DAO放在了领域层。

  实体：拥有唯一标识符，且标识符在经历过各种状态变更后仍能保持一致。领域模型中的实体是多个属性、操作或行为的载体。DDD中使用的是充血模型，即实体中包含属性与行为。

  值对象：通过对象属性值来识别的对象，它将多个相关属性组合为一个概念整体。在DDD中用来描述领域的特定方面，并且是一个没有标识符的对象。值对象所描述的领域只的这个东西它是不可变的，只能替换值对象，不能修改一个值对象。

  聚合：实体和值对象有规则的组合。有规则体现在它将这些原本平等的实体或值对象分了等级，从中选出一个叫聚合根的实体负责人负责这个聚合。聚合根除了负责自身的业务逻辑，还负责在聚合内部协调实体和值对象按照固定的业务规则协同完成共同的业务逻辑。它还是聚合对外的接口人，以聚合根ID关联的方式接受外部任务和请求，在上下文内实现聚合之间的业务协同。

  领域服务：领域层面向对外的一种服务，它一般对同一个实体的一个或多个方法进行组合和封装，或对多个不同实体的操作进行组合或编排，对外暴露成领域服务。目的是为了隐藏领域层的业务逻辑实现。

  仓储：存储数据的仓库，不过和数据库不同在于，数据库用于存取数据，仓储是为了存储持久化数据。从架构层面来说，仓储用于连接领域层和基础结构层，仓储的作用对象的领域模型的聚合根，也就是说每一个聚合都有一个单独的仓储。

• 基础层：不仅处理数据库相关事宜，还负责网关、缓存、第三方工具、基础组件等。

分层架构的一个重要原则是每层只能与位于其下方的层发生耦合。分层架构可以简单分为两种，即严格分层架构和松散分层架构。在严格分层架构中，某层只能与位于其直接下方的层发生耦合，而在松散分层架构中，则允许某层与它的任意下方层发生耦合。一般我们常使用的是DDD优化后的严格分层架构，优化后的分层架构将领域层作为核心，放在最下方。

综上所述，DDD分层架构是一种基于领域驱动设计思想的软件架构模式，它通过分层的方式将软件模块进行划分，并明确了每层的功能和职责。这种架构模式有助于提高软件的可维护性、可扩展性和可重用性。