正文
烽烟
哈喽大家周二好呀，咱们又见面了，上周末掐指一算，距离 圣诞节 只有 5 周的时间了（如果你还不知道为啥我要提圣诞节这个时间点，可以看看我的第二系列开篇《之一 ║ D3模式设计初探 与 我的计划书》），然后我简单的思考了下这个DDD领域驱动设计还剩下的知识点，现在已经进入了第二部分，就是领域命令和领域驱动这一块，第三部分包括Identity验证和.net core api等设计点，大概就是剩了这么多，预计应该能在圣诞节前完成。还有一个就是，之前的八篇文章，已经比较完整的实现了普通框架的整体搭建，我也单独的新建了一个 Git分支——Framework8 ，如果你不想用领域命令、领域事件、事件回溯这些东西，仅仅就想要一个空的框架，一个包括 EFCore+Dtos+Automapper+IoC+Repository 的空框架（就比如我的第一个系列，就是一个普通的框架，请不要再说是这是一个普通三层了，拜托😂），你就可以直接用这个Framework8 分支即可。
言归正传，上次咱们说到了创建新student的时候，提出来一个问题，不知道大家是否还记得，这里再给大家说明一下，还是每篇一问，希望能好好思考下，或者是看看自己是如何设计的：
问题1：平时是如何进行表单验证的（包括：判空、字符类型有效、业务验证：成人不能小于18岁、金额不能小于0等）？
问题2：如果后来验证变化了改怎么办？（比如：手机号要支持全球，或者座机；亦或者退休年龄从60岁变成65岁；）
1、JavaScript前端验证即可，后端从来不进行验证？（问题2：修改js）
2、后端验证：直接在Controller中，通过写很多判断逻辑，比如 If Else等，而且CURD还需要写很多重复的判断方法？（问题2：每一个地方都需要仔细修改，额。）
3、后端验证：写一个统一的验证类，或者验证机制，比如一个公共类？甚至更高级的AOP切面验证？（问题2：好像还是无法满足每个领域特例）
4、后端验证：在DTO基础上，基于领域命令，通过中介者Bus分发？（当然这个就是以后我要写的）
其实说实话，前三种我都用过，甚至现在偶尔也还是会用，毕竟很平常的用法，但是现在我感觉第四种真的很整洁，真正的把整体项目放到了领域中，一切以领域为核心了 。这里我先把第四种的应用层 Service 方法简单写下，你就知道多么简洁了，具体的会在下面两篇文章中说到：
/// <summary> /// StudentAppService 添加新 Student /// </summary> public void Register(StudentViewModel studentViewModel) { //讲视图模型，转换成命名模型 var registerCommand = _mapper.Map<RegisterStudentCommand>(studentViewModel);
