DDD浅析项目数据流

18 篇文章 0 订阅
13 篇文章 0 订阅

DDD(领域驱动设计)总体结构分为四层: Infrastructure(基础实施层),Domain(领域层),Application(应用层),Interfaces(表示层,也叫用户界面层或是接口层),
各个层面的作用下面介绍:

  1. 用户界面(表现层):负责给用户展示信息,并解释用户命令。
  2. 应用层:该层协调应用程序的活动。不包括任何业务逻辑,不保存业务对象的状态,但能保存应用程序任务过程的状态。(主要是调用领域层的接口如集群部署就放在这层,同时也能防止循环依赖)
  3. 领域层:这一层包括业务领域的信息。业务对象的状态在这里保存。业务对象的持久化和它们的状态可能会委托给基础设施层。(简单说就是对表对象增删改查的操作接口,真正的实现在基础设施层)
  4. 基础设施层:对其它层来说,这一层是一个支持性的库。它提供层之间的信息传递,实现业务对象的持久化,包含对用户界面层的支持性库等。

其实不管后端用什么语言:对 POST请求后端处理是类似的,比如:post参数校验和反序列化输入
比如对于 POST 请求,需要把用户的输入反序列化到后端类中。
Python Django 中的:
	在视图类里指定:serializer_class = DataBaseInfoSerializer 
	然后在序列化类 DataBaseInfoSerializer 里自定义 validate 方法实现 post 参数校验,
	当然也可以对在定义序列化类的字段时指定一些是否必填等基础校验 
	db_host = serializers.CharField(allow_null=True, required=False)
	然后在视图类里得到校验后和序列化后的数据:
	data = serializer.validated_data; 
	 
GoLang Beego 中的:
    在视图函数中:
    var v models.BackupPlanInput
  	err := json.Unmarshal(c.Ctx.Input.RequestBody, &backuPlanInput)
	valid := validation.Validation{}
	b, err := valid.Valid(&v)
    在结构体  models.BackupPlanInput 中实现方法 Valid 就能做到 post 参数校验
	func (p *BackupPlanInput) Valid(v *validation.Validation) {
	}
	
Java SpringBoot 中的:在 DTO 类里通过注解实现 post 参数基本校验
	FlowOrder flowOrder = flowOrderAssembler.dtoToEntity(dto)

Q: 为什么要分这么多层?DTO、实体类、DO
A:其实是给了一次做转换的机会即有一次处理数据的机会,比如:
DTO到实体类:即“用户输入”到“领域层实体类”的转换:
    比如对于性别前端输入的是男女,后端存储0和1
实体类到DO:即 “领域层实体类”到“基础设施层的DO”的转换
    比如通常后端数据库表中会增加逻辑删除字段和 版本控制 version 字段
这也吻合了一句名言:在计算机里,任何问题都可以通过加中间转换层来解决

DOT到实体类的转换示例:通过 expression  做自定义的处理

package com.jdd.flowmanager.interfaces.facade.assembler;
import com.jdd.flowmanager.domain.entity.FlowOrder;
import com.jdd.flowmanager.infrastructure.utils.JacksonUtils;
import com.jdd.flowmanager.interfaces.facade.dto.FlowOrderDTO;
import com.jdd.flowmanager.interfaces.facade.viewobject.FlowOrderVO;
import org.mapstruct.*;
import org.mapstruct.factory.Mappers;	
import java.util.List;
import java.util.Map;

@Mapper(
    nullValueMappingStrategy = NullValueMappingStrategy.RETURN_NULL,
    nullValuePropertyMappingStrategy = NullValuePropertyMappingStrategy.IGNORE,
    nullValueCheckStrategy = NullValueCheckStrategy.ALWAYS
)
public interface FlowOrderAssembler {
	
   FlowOrderAssembler INSTANCE = Mappers.getMapper(FlowOrderAssembler.class);

    /**
     * DTO转实体
     *
     * @param dto DTO
     * @return 实体
     */
    @Mapping(expression = "java(MapStructExpression.mapToStr(dto.getOrderDetails()))", target = "orderDetails")
    FlowOrder dtoToEntity(FlowOrderDTO dto);

    /**
     * 实体转VO
     *
     * @param entity entity
     * @return ViewObject
     */
    FlowOrderVO entityToVO(FlowOrder entity);
}
	
class MapStructExpression {
    public static String mapToStr(Map<String, Object> map){
        return JacksonUtils.toJson(map);
    }
}

在这里插入图片描述

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
### 回答1: DDD(领域驱动设计)是一种软件架构风格,它强调在设计软件时要着重于领域模型。领域模型是专门用来表示业务领域的模型,它的目的是帮助理解和描述业务流程。 在DDD项目中,通常会有一个专门用来存放领域模型的目录,这个目录通常被称为“领域层”(domain layer)或“领域模型层”(domain model layer)。这个目录中通常会包含以下内容: - 实体(entity):表示业务中的持久化对象,例如客户、订单等。 - 值对象(value object):表示业务中的不可变对象,例如地址、颜色等。 - 抽象基类(abstract base class):为实体和值对象提供公共的属性和方法。 - 仓储接口(repository interface):定义了对实体的持久化操作的方法,例如保存、查询等。 - 服务接口(service interface):定义了与业务流程相关的方法,例如创建订单、计算价格等。 通常情况下,这些内容都会被放在单独的文件或文件夹中,以方便维护和管理。 此外 ### 回答2: DDD(领域驱动设计)数据领域模型项目目录结构可以按照以下方式组织: 1. 应用层(Application Layer):这个目录包含了应用层的代码,主要负责接收并处理用户的请求,协调各个领域服务的调用。其中可能包括处理用户身份验证、授权、输入参数校验等功能。 2. 领域层(Domain Layer):这个目录包含了领域模型的代码,用来表示业务领域中的概念、规则和逻辑。其中可能包括实体(Entity)、值对象(Value Object)、领域服务(Domain Service)等。 3. 基础设施层(Infrastructure Layer):这个目录存放与基础设施相关的代码,用来处理与外部系统的交互和数据持久化。可能包括数据库操作、消息队列、缓存、外部API调用等。 4. 接口层(Interface Layer):这个目录用来定义与外部系统交互的接口,可以包括RESTful API、GraphQL接口、消息队列接口等。 5. 共享内核(Shared Kernel):这个目录存放一些通用的领域模型、工具类、扩展方法等,可以被整个项目共用。 6. 测试目录(Test):这个目录存放各个层面的测试代码,包括单元测试、集成测试、端到端测试等。 7. 配置文件(Config):这个目录存放项目的配置文件,可以包括数据库连接配置、日志配置、缓存配置等。 以上仅是一种可能的DDD项目目录结构,具体结构可以根据项目的规模、复杂度和需求来进行调整和扩展。重要的是保持代码的组织结构清晰,遵循领域驱动设计的原则,将业务逻辑和领域概念体现在代码中,提高代码的可读性和可维护性。 ### 回答3: DDD(领域驱动设计)数据领域模型项目的目录结构会根据具体项目的需求和技术栈而有所不同,但一般包括以下几个核心部分: 1. 领域模型层(Domain Model):包含了业务领域的核心概念、实体对象和值对象等。在这个目录中,可以根据业务域划分包或文件来组织模型,比如可以有用户(User)、订单(Order)、产品(Product)等业务领域模型。 2. 应用服务层(Application Services):负责处理应用层与领域模型之间的交互逻辑。这个目录中通常会包含一些应用服务接口(接口定义)和实现类,它们调用领域模型层,提供一些对外的接口供上层应用(如控制器)调用。 3. 基础设施层(Infrastructure):包含了与外部系统的交互、数据存储等功能。这个目录中可能包含一些与数据库相关的代码、与外部服务交互的代码等。比如可以有数据库访问层、第三方服务接口层等。 4. 用户界面层(User Interface):负责与用户进行交互,通常包含了控制器、表现层逻辑和前端页面等。这个目录中可以包含一些控制器、视图模板、静态资源等。 5. 配置文件和脚本:项目的一些配置文件和部署脚本等。这些文件可以包括数据库连接配置、日志配置、缓存配置等。 以上是一个基本的目录结构,但实际项目中可以根据具体需求进行调整和扩展。根据项目的规模和复杂性,可以进一步划分子目录,或者引入模块化的设计来组织代码结构。在DDD项目中,目录结构的合理组织可以提高代码的可读性和可维护性,同时也更好地支持领域模型的驱动设计思想。

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值