首页 > 极客资料 博客日记
这就是为什么你学不会DDD
2024-08-13 12:30:02极客资料围观22次
这篇文章介绍了这就是为什么你学不会DDD,分享给大家做个参考,收藏极客之家收获更多编程知识
本文书接上回《为了给Javaer落地DDD,我们不得不写开源组件》,欢迎关注公众号(老肖想当外语大佬),获取最新文章更新和DDD框架源码,视频和直播在B站。
背景
我们在《这是DDD建模最难的部分(其实很简单)》一文中介绍了一个关于“用户-角色”的建模过程,当我们讨论“如何分析业务和建模,以在满足需求的前提下,使得需求和模型的边界都清晰且一致”这一话题时,发现很多经验丰富的开发者,总会带着各种各样的顾虑和疑惑,“数据库里的表关系怎么处理”,“关联查询不就解决问题了吗?”,“为啥不能关联查询?”,“既然有了某某Id,说明它们有关系啊,你为啥说边界明确?”。
我就在想,这里的问题到底在哪里,为什么我们觉得理所当然的想法,仍然有很多人会觉得困惑,经过和我们团队伙伴们深入探讨,我觉得我们找到了问题所在。
知识的诅咒
我记得在《倚天屠龙记》中有这么一幕,张三丰现场传授张无忌太极剑法,教完之后,问张无忌好几遍:“还记得多少?”,张无忌最后说:“我已经把所有的全忘记了!”,张三丰很高兴:“好,你可以上了。”
回到我们软件设计的场景,我们经验丰富的工程师,总是会深思熟虑,会考虑性能够不够?模型怎么存到表里?表结构是否合理?这里应该一对一关系还是一对多?又或者应该是多对多?这一系列的问题使得大家无法集中精力思考业务的本质是什么,过早地把注意力放在了技术上,在跟业务专家热烈沟通客户场景的时候,你的脑海里却满满的SQL语句怎么写。
我想,这大概就是知识的诅咒吧,背负着沉重的心智负担,大概率也做不出更准确的判断。
忘掉数据库
现在假设科技已经发展到了非常顶级的水准,我们具备了如下能力:
- 应用程序的内存无限大;
- 应用程序内存永远不会丢失;
那么,我们还需要数据库吗?我想,应该不需要了,我们代码会是怎么样的?是不是在内存中构造出模型的实例添加到它的集合容器中,就可以了?
假如不再需要数据库了,你建模的时候是不是可以忘掉数据库,把模型看作是一个个独立的类型实例即可?你的建模思路是否会发生一些变化?那么在这个背景下,我们重新审视“领域的边界”这个概念。
假如我们仍然使用之前的文章中提到的准则:“聚合之间不存在相互引用”,那么你设计出来的结果是不是就会像我们之前推演的那样,像下图一样:
如果你仍然有疑惑,我把具体的类图也添加进来,你是不是就一目了然了:
回到现实
当然,现实是我们的科技并没有像上面设想的那样发达,我们最终还是要将模型数据存储到数据库的,因此,我们需要ORM框架来帮助我们解决模型的“存取”问题,注意这里我用到的是“存取”,不包含搜索,搜索的事情,我们可以用更加灵活的解决方案,这涉及到一种叫做CQRS的模式,这又是另一个故事了。
假如我们有一个很强大的ORM,可以帮助我们根据Id,取出模型,我们操作完模型,ORM再帮我们“Save”进数据库,我们不需要关心这里面它到底做了什么,那么是不是这个ORM也可以帮助我们摆脱“数据库知识”的诅咒,让我们在建模的时候专注需求和模型?
结论是什么
基于上面的推导,我认为有如下结论:
- 数据库知识,会成为分析需求和建模时候的心智负担;
- 一个功能强大的ORM,有利于帮助工程师摆脱“数据库知识”的心智负担;
- 分析需求的时候,只需要关心需求和模型即可;
那么,你对上面的结论有什么看法?你在用什么样的ORM?你参与的项目的代码组织方式,是否让你可以专注业务?欢迎在文章评论区友善地讨论,也欢迎关注我的公众号(老肖想当外语大佬)以获得最新的更新。
后续
下一篇,我将介绍一种能够在各个角色间建立共鸣的建模沟通方法,以使得我们的建模思维可以落地和复制,敬请期待。
版权声明:本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若内容造成侵权/违法违规/事实不符,请联系邮箱:jacktools123@163.com进行投诉反馈,一经查实,立即删除!
标签:
相关文章
最新发布
- Nuxt.js 应用中的 prerender:routes 事件钩子详解
- 【问题解决】Tomcat由低于8版本升级到高版本使用Tomcat自带连接池报错无法找到表空间的问题
- 【FAQ】HarmonyOS SDK 闭源开放能力 —Vision Kit
- 六、Spring Boot集成Spring Security之前后分离认证流程最佳方案
- 《JVM第7课》堆区
- .NET 8 高性能跨平台图像处理库 ImageSharp
- 还在为慢速数据传输苦恼?Linux 零拷贝技术来帮你!
- 刚毕业,去做边缘业务,还有救吗?
- 如何避免 HttpClient 丢失请求头:通过 HttpRequestMessage 解决并优化
- 让性能提升56%的Vue3.5响应式重构之“版本计数”