这就是为什么你学不会DDD

本文书接上回《为了给Javaer落地DDD，我们不得不写开源组件》，,关注公众号（老肖想当外语大佬）获取信息：

1. 最新文章更新；
2. DDD框架源码（.NET、Java双平台）；
3. 加群畅聊，建模分析、技术实现交流；
4. 视频和直播在B站。

https://mp.weixin.qq.com/s/Nsc3hwl4u9je7DaXsC05mg

背景

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

我就在想，这里的问题到底在哪里，为什么我们觉得理所当然的想法，仍然有很多人会觉得困惑，经过和我们团队伙伴们深入探讨，我觉得我们找到了问题所在。

知识的诅咒

我记得在《倚天屠龙记》中有这么一幕，张三丰现场传授张无忌太极剑法，教完之后，问张无忌好几遍：“还记得多少？”，张无忌最后说：“我已经把所有的全忘记了！”，张三丰很高兴：“好，你可以上了。”

回到我们软件设计的场景，我们经验丰富的工程师，总是会深思熟虑，会考虑性能够不够？模型怎么存到表里？表结构是否合理？这里应该一对一关系还是一对多？又或者应该是多对多？这一系列的问题使得大家无法集中精力思考业务的本质是什么，过早地把注意力放在了技术上，在跟业务专家热烈沟通客户场景的时候，你的脑海里却满满的SQL语句怎么写。

我想，这大概就是知识的诅咒吧，背负着沉重的心智负担，大概率也做不出更准确的判断。

忘掉数据库

现在假设科技已经发展到了非常顶级的水准，我们具备了如下能力：

1. 应用程序的内存无限大；
2. 应用程序内存永远不会丢失；

那么，我们还需要数据库吗？我想，应该不需要了，我们代码会是怎么样的？是不是在内存中构造出模型的实例添加到它的集合容器中，就可以了？

假如不再需要数据库了，你建模的时候是不是可以忘掉数据库，把模型看作是一个个独立的类型实例即可？你的建模思路是否会发生一些变化？那么在这个背景下，我们重新审视“领域的边界”这个概念。

假如我们仍然使用之前的文章中提到的准则：“聚合之间不存在相互引用”，那么你设计出来的结果是不是就会像我们之前推演的那样，像下图一样：

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

回到现实

当然，现实是我们的科技并没有像上面设想的那样发达，我们最终还是要将模型数据存储到数据库的，因此，我们需要ORM框架来帮助我们解决模型的“存取”问题，注意这里我用到的是“存取”，不包含搜索，搜索的事情，我们可以用更加灵活的解决方案，这涉及到一种叫做CQRS的模式，这又是另一个故事了。

假如我们有一个很强大的ORM，可以帮助我们根据Id，取出模型，我们操作完模型，ORM再帮我们“Save”进数据库，我们不需要关心这里面它到底做了什么，那么是不是这个ORM也可以帮助我们摆脱“数据库知识”的诅咒，让我们在建模的时候专注需求和模型？

结论是什么

基于上面的推导，我认为有如下结论：

1. 数据库知识，会成为分析需求和建模时候的心智负担；
2. 一个功能强大的ORM，有利于帮助工程师摆脱“数据库知识”的心智负担；
3. 分析需求的时候，只需要关心需求和模型即可；

那么，你对上面的结论有什么看法？你在用什么样的ORM？你参与的项目的代码组织方式，是否让你可以专注业务？欢迎在文章评论区友善地讨论，也欢迎关注我的公众号（老肖想当外语大佬）以获得最新的更新。

后续

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