DDD中数据的校验

最新推荐文章于 2023-12-28 09:17:46 发布
最新推荐文章于 2023-12-28 09:17:46 发布
阅读量2.3k 收藏
点赞数
分类专栏： SoftwareDesign 文章标签： DDD validate repository controller data
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/kamputer/article/details/91363818
版权

入参校验

Controller校验

  • 可以更友好的返给前端信息
  • 可以在一开始就检查完毕，特别是一个Controller方法对应两个Domain方法的情况下

Domain校验

  • 可以处理不同Domain之间的差异

数据库中数据校验

Repository校验

  • 作为数据存储方提供数据的完整性，domain只解决业务问题
  • 可以对id不存在的进行进行处理
  • 可以处理冗余字段的一致性

Domain.retrieve校验

  • 默认值的处理，本身有业务上的考量
首席IT民工
关注
专栏目录
DDD领域驱动设计实战-服务和数据在微服务各层协作的最佳实践
a6636656的博客
08-07 916
表述应用和用户行为，负责服务的组合、编排和转发，负责处理业务用例的执行顺序以及结果的拼装，负责不同聚合之间的服务和数据协调，负责微服务之间的事件发布和订阅。虽然实体、实体方法和领域服务都在领域层，但实体和实体方法只能暴露给领域服务，领域服务只能暴露给应用服务。当实体方法或领域服务发生变更，由于服务同时被多层服务调用和组合，难以找出哪些上层服务调用和组合了它，不方便通知到所有的服务调用方。用来表述应用和用户行为，负责服务的组合、编排和转发，负责处理业务用例的执行顺序以及结果拼装，对外提供粗粒度的服务。...
JRS303数据校验
qq_60803513的博客
06-02 728
初始Jrs
领域驱动DDD之供应链多渠道（华泊、唯品、京东等等）地址库匹配下单地址校验下单流程
lin451791119的博客
08-20 1096
绝大多数项目都需要涉及到地址库，我曾经负责过的电商系统，各个渠道（中间商，包括唯品、华泊渠道 ）的地址库数据是不一样，比如相同地址的中文不同，或者地址编码不同，为了能够正常下单，我们建立了地址库并且通过"渠道ID"的方式去映射对应的地址，我们的地址库是TBL地址库，唯品的地址库是VIP地址库，华泊的地址库是HUABO地址库。 tbl_hua_bo_districts是TBL地址库的表名，项目的线上数据库使用的是Mongodb。 huabo_address是华泊HUABO地址库的表名。 为了匹配
领域对象之参数校验
jwq201288888888的专栏
11-03 686
引子         在做java web服务端时，经常要处理http请求传入参数的校验。从最开始的源生代码校验到校验方法的封装再到使用注解封装校验逻辑等，目的是在完成校验任务的基础上简化校验部分代码工作量。 @GetMapping("test") public ResultInfo testInfo(TestBean demo){ if(demo.getId() == null |...
DDD学习和总结
weixin_41909330的博客
09-22 232
业务评判 接口清晰度 根据接口和参数，可以清晰的知道接口能力； 数据验证和错误处理 数据校验应该遵循DRY（Don‘t repeat youself）， 业务代码清晰度 业务只有业务，没有其他逻辑， 可测性 业务的TC（Test Case）是可控的 DP：domain primitive 将隐性概念显性化 姓名（String），手机号（String），地址（String） 姓名（Name），手机号（Phone），地址（Adress） 不要使用String标示以上信息，要使用对应的VO（View Object
DDD：群里关于验证的结论
weixin_33859231的博客
07-01 137
@汤雪华 验证是为了让数据符合要求。各个层的验证是为了确保传递给各个层的数据符合当前层所需要的数据的要求。 @小学僧 db model的验证主要是为了保证数据完整。 domain model的验证主要是为了保证业务完整。 view model的验证主要是为了用户体验。 领域模型能否处于非法状态？ 如果采用领域驱动，我不会让领域模型处于非法状态的。 如果采用贫血模型，我会。...
DDD初步简单理解
ybbgrain的历程
10-13 917
DDD的初步理解
ddd.rar_www.03ddd_www.DDD89.com
09-23
标题中的"ddd.rar_www.03ddd_www.DDD89.com"表明这是一个压缩文件，可能包含了某个项目或资源的代码、文档等，而URL部分可能是发布者或来源的标识，但具体网址已无效。 描述中提到的是一个89S52微控制器与射频卡...
ddd模型 java中使用_DDD-领域驱动设计示例
weixin_36440941的博客
03-01 3037
一、DDD概述DDD，即领域驱动设计，核心是不断提炼通用语言并用于与领域专家等团队所有成员交流，并用代码来表达出一个与通用语言一致的领域模型。通用语言：通过团队交流达成共识的能够简单清晰准确传递业务规则的语言(可以是文字、图片等)领域：软件系统要解决的问题域，是有边界的。领域一般包含多个子域，子域根据其功能划分为核心域、通用域、支撑域。限界上下文：描述领域边界，一个限界上下文可能包含多个子域，但一...
领域驱动设计DDD和CQRS落地
jiangbb8686的博客
12-31 3782
DDD分层架构 Evans在它的《领域驱动设计：软件核心复杂性应对之道》书中推荐采用分层架构去实现领域驱动设计： image 其实这种分层架构我们早已驾轻就熟，MVC模式就是我们所熟知的一种分层架构，我们尽可能去设计每一层，使其保持高度内聚性，让它们只对下层进行依赖，体现了高内聚低耦合的思想。 分层架构的落地就简单明了了，用户界面层我们可以理解成web层的Controller，应用层和...
应用程序框架实战十五:DDD分层架构之领域实体（验证篇）
weixin_33859504的博客
11-20 266
　　在应用程序框架实战十四:DDD分层架构之领域实体（基础篇）一文中，我介绍了领域实体的基础，包括标识、相等性比较、输出实体状态等。本文将介绍领域实体的一个核心内容——验证，它是应用程序健壮性的基石。为了完成领域实体的验证，我们在前面已经准备好了验证公共操作类和异常公共操作类。 　　.Net提供的DataAnnotations验证方法非常强大，Mvc会自动将DataAnnotations特性转换...
DDD领域模型和持久模型的实施方式（不定期更新ing）
weixin_34013044的博客
01-11 205
为什么80%的码农都做不了架构师？>>> ...
【DDD】领域驱动设计1 DP
h201601060805的博客
07-18 539
假设现在需要对手机号注册时的身份信息和入参中的用户名进行一致性校验，（获取手机号注册时的身份信息是一个外部依赖项）如果在PhoneNumber内部实现，让phoneNumber内依赖其他查询服务似乎是不合适的，那么，这部分逻辑该怎么抽象怎么写？我们定义了一个User类，一个注册接口的具体实现类，注册方法中先对参数进行校验，然后通过手机号获取归属地编号和运营商编号，存到user中，我们新型的基本单元不仅有属性，还有属性相关的职责，是充血模型的一种，如何把握。将客户群体分组，分配给相应的销售组，...
DDD架构下的防御式编程：5大关卡共同保障业务数据的有效性
Java知音
10-08 154
1. 规则验证是准确性的基础规则验证是业务稳定性的重要保障手段，通过规则验证，可以验证和确保系统或业务逻辑的正确性和合规性，避免潜在的错误和问题。而规则的遗漏往往会伴随着线上bug的出现。相信每个开发人员都曾面对过以下情况：未对入参进行非空判断，在执行逻辑时导致空指针异常（NullPointerException，简称NPE）;未正确验证用户权限，导致未授权操作发生，普通用户也能执行该操作，最终产...
DDD领域驱动设计内容分享(七)：DDD中Interface层、Application层的设计规范
最新发布
之乎者也·的博客
12-28 1816
这里举一个简单的常见案例：下单链路。假设我们在做一个checkout接口，需要做各种校验、查询商品信息、调用库存服务扣库存、然后生成订单：@Resource@Resource@Resource// 1) Session管理// 2）参数校验// 3）外部数据补全// 4）调用外部服务if (!// 5）领域计算// 6）领域对象操作// 7）数据持久化// 8）返回为什么这种典型的流水账代码在实际应用中会有问题呢？
DDD之Domain Primitive（DP）
weixin_42596778的博客
07-20 3204
前言： DDD是一种架构思想，而不是一套框架。 Domain Primitive: 何为DP，他是DDD中的“基础数据结构”，就像Java中的int，string一样，是我们学习的必经之路。这么说有点抽象，接下来通过一个案例来说明。 用户注册功能，需要输入用户的名字，电话（带区号的座机），地址。并且后台需要根据电话信息来统计哪个区域注册用户最多。那么就可以看出来电话需要自己的校验逻辑，来判断号码是否合法，以及拆分出区号。 传统的方式： public class User { String name;
结合DDD讲清楚：后端系统分析七大维度（长文多图）
BASK2311的博客
02-20 262
本文通过一个业务实例介绍了开发文档七大维度：四色分领域、用例看功能、流程三剑客、领域与数据、纵横做设计、分层看架构、接口看对接。每个维度描述系统的一个侧面，组合在一起最终描绘出整个系统。在实际开发中如果需求不大，那么也不是这七个维度都要体现，而是根据实际情况作取舍，能够把方案说清楚即可，希望本文对大家有所帮助。欢迎大家关注公众号「JAVA前线」查看更多精彩分享文章，主要包括源码分析、实际应用、架构思维、职场分享、产品思考等等，同时欢迎大家加我个人微信「java_front」一起交流学习。
领域驱动设计（DDD）基本概念的自我理解
皇家程序猿
03-03 427
DDD个人主要理解 它微服务的设计思想 主要由子域与边界上下文组成 子域：领域驱动为每一个子域设计独立的领域模型，每一个子对应着一个业务 边界上下文：子域的边界 它是对面向对象设计的增强 与数据驱动的区别 数据驱动：我们传统的代码架构是dao、service、controller三层组成，大多数的业务本质是对数据库表的增删改查（比如开发一个简单用户注册系统） 数据驱动的痛点： （1） 存在接口定义不狗清晰（参数定义不够清晰，比如都用string类型去接收） （2） 存在业务代码不够清晰（比如核心业务代码中
DDD数据领域模型项目目录结构
08-23
### 回答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、付费专栏及课程。

余额充值