本文书接上回《
为了给Javaer落地DDD,我们不得不写开源组件
》,欢迎关注公众号(老肖想当外语大佬),获取最新文章更新和DDD框架源码,视频和直播在B站。

背景

我们在《这是DDD建模最难的部分(其实很简单)》一文中介绍了一个关于“用户-角色”的建模过程,当我们讨论“如何分析业务和建模,以在满足需求的前提下,使得需求和模型的边界都清晰且一致”这一话题时,发现很多经验丰富的开发者,总会带着各种各样的顾虑和疑惑,“数据库里的表关系怎么处理”,“关联查询不就解决问题了吗?”,“为啥不能关联查询?”,“既然有了某某Id,说明它们有关系啊,你为啥说边界明确?”。
我就在想,这里的问题到底在哪里,为什么我们觉得理所当然的想法,仍然有很多人会觉得困惑,经过和我们团队伙伴们深入探讨,我觉得我们找到了问题所在。

知识的诅咒

我记得在《倚天屠龙记》中有这么一幕,张三丰现场传授张无忌太极剑法,教完之后,问张无忌好几遍:“还记得多少?”,张无忌最后说:“我已经把所有的全忘记了!”,张三丰很高兴:“好,你可以上了。”
回到我们软件设计的场景,我们经验丰富的工程师,总是会深思熟虑,会考虑性能够不够?模型怎么存到表里?表结构是否合理?这里应该一对一关系还是一对多?又或者应该是多对多?这一系列的问题使得大家无法集中精力思考业务的本质是什么,过早地把注意力放在了技术上,在跟业务专家热烈沟通客户场景的时候,你的脑海里却满满的SQL语句怎么写。
我想,这大概就是
知识的诅咒
吧,背负着沉重的心智负担,大概率也做不出更准确的判断。

忘掉数据库

现在假设科技已经发展到了非常顶级的水准,我们具备了如下能力:
  1. 应用程序的内存无限大;
  2. 应用程序内存永远不会丢失;
那么,我们还需要数据库吗?我想,应该不需要了,我们代码会是怎么样的?是不是在内存中构造出模型的实例添加到它的集合容器中,就可以了?
假如不再需要数据库了,你建模的时候是不是可以忘掉数据库,把模型看作是一个个独立的类型实例即可?你的建模思路是否会发生一些变化?那么在这个背景下,我们重新审视“领域的边界”这个概念。
假如我们仍然使用之前的文章中提到的准则:“
聚合之间不存在相互引用
”,那么你设计出来的结果是不是就会像我们之前推演的那样,像下图一样:

如果你仍然有疑惑,我把具体的类图也添加进来,你是不是就一目了然了:

回到现实

当然,现实是我们的科技并没有像上面设想的那样发达,我们最终还是要将模型数据存储到数据库的,因此,我们需要ORM框架来帮助我们解决模型的“存取”问题,注意这里我用到的是“存取”,不包含搜索,搜索的事情,我们可以用更加灵活的解决方案,这涉及到一种叫做CQRS的模式,这又是另一个故事了。
假如我们有一个很强大的ORM,可以帮助我们根据Id,取出模型,我们操作完模型,ORM再帮我们“Save”进数据库,我们不需要关心这里面它到底做了什么,那么是不是这个ORM也可以帮助我们摆脱“数据库知识”的诅咒,让我们在建模的时候专注需求和模型?

结论是什么

基于上面的推导,我认为有如下结论:
  1. 数据库知识,会成为分析需求和建模时候的心智负担;
  2. 一个功能强大的ORM,有利于帮助工程师摆脱“数据库知识”的心智负担;
  3. 分析需求的时候,只需要关心需求和模型即可;
那么,你对上面的结论有什么看法?你在用什么样的ORM?你参与的项目的代码组织方式,是否让你可以专注业务?欢迎在文章评论区友善地讨论,也欢迎关注我的公众号(老肖想当外语大佬)以获得最新的更新。

后续

下一篇,我将介绍一种能够在各个角色间建立共鸣的建模沟通方法,以使得我们的建模思维可以落地和复制,敬请期待。

标签: none

添加新评论