DDD架构中数据传递的过程

DDD架构中如何domain层和infrastructure如何传递数据,以及作用

传统的三层架构

传统的三层架构包括表示层、业务逻辑层和数据访问层,它的设计目标是将系统划分为独立的、高内聚、低耦合的模块,使得每个模块的职责清晰、易于维护和升级。在这种架构中,业务逻辑层是系统的核心,它处理所有的业务逻辑,而表示层和数据访问层则分别负责与用户交互和访问数据。

MVC模式中业务逻辑层直接与数据访问层交互,导致与数据层面有较强的依赖关系,以致于不便后续数据层面的更新,并且也会导致自身的庞大和臃肿,不便后续的维护。

领域驱动设计的四层架构

领域驱动设计的四层架构则更加强调领域模型的设计和实现,它包括表示层、应用层、领域层和基础设施层。在这种架构中,领域层是系统的核心,它包含了系统的领域模型和业务逻辑,而应用层负责协调各个领域层的操作,提供应用程序的服务接口,表示层负责与用户交互,基础设施层负责提供与外部系统的交互和数据存储等服务。

领域层只关注业务逻辑的实现,提供领域数据的接口,而不关注具体数据如何操作,基础层实现领域层提供的接口,配合DAO和po完成具体的方法。

领域层包结构

activity, award,strategy是三个领域,领域下在repository包中定义具体的数据接口。

基础层包结构

dao包含数据访问逻辑,po是持久化对象,repository是对领域层提供的接口的实现

在infrastructure层下实现这些接口,DAO做数据层面的交互,处理数据访问逻辑,可以实现解耦合。

并且,仓储层可以在领域模型的操作之上实施领域规则。这意味着在执行数据访问操作之前或之后,可以在仓储中添加额外的逻辑来保持领域模型的一致性和完整性。

仓储层可以负责将基础设施层的数据映射为领域模型所需的数据结构,以及将领域模型的数据转换为基础设施层所需的格式。这种转换和映射逻辑可以在仓储中集中处理,减少领域模型与基础设施层之间的耦合。如转换成聚合根。

过在仓储层中定义接口,可以实现技术的灵活性,使得可以更换底层数据访问技术或使用不同的数据存储策略,而无需修改领域模型。同时,仓储接口也有助于编写针对领域模型的单元测试,因为可以使用模拟或存根实现来模拟数据访问。