我们在《这是DDD建模最难的部分（其实很简单）》一文中介绍了一个关于“用户-角色”的建模过程，当我们讨论“如何分析业务和建模，以在满足需求的前提下，使得需求和模型的边界都清晰且一致”这一话题时，发现很多经验丰富的开发者，总会带着各种各样的顾虑和疑惑，“数据库里的表关系怎么处理”，“关联查询不就解决问题了吗？”，“为啥不能关联查询？”，“既然有了某某Id，说明它们有关系啊，你为啥说边界明确？”。
我就在想，这里的问题到底在哪里，为什么我们觉得理所当然的想法，仍然有很多人会觉得困惑，经过和我们团队伙伴们深入探讨，我觉得我们找到了问题所在。
我记得在《倚天屠龙记》中有这么一幕，张三丰现场传授张无忌太极剑法，教完之后，问张无忌好几遍：“还记得多少？”，张无忌最后说：“我已经把所有的全忘记了！”，张三丰很高兴：“好，你可以上了。”
回到我们软件设计的场景，我们经验丰富的工程师，总是会深思熟虑，会考虑性能够不够？模型怎么存到表里？表结构是否合理？这里应该一对一关系还是一对多？又或者应该是多对多？这一系列的问题使得大家无法集中精力思考业务的本质是什么，过早地把注意力放在了技术上，在跟业务专家热烈沟通客户场景的时候，你的脑海里却满满的SQL语句怎么写。
我想，这大概就是知识的诅咒吧，背负着沉重的心智负担，大概率也做不出更准确的判断。
现在假设科技已经发展到了非常顶级的水准，我们具备了如下能力：
那么，我们还需要数据库吗？我想，应该不需要了，我们代码会是怎么样的？是不是在内存中构造出模型的实例添加到它的集合容器中，就可以了？
假如不再需要数据库了，你建模的时候是不是可以忘掉数据库，把模型看作是一个个独立的类型实例即可？你的建模思路是否会发生一些变化？那么在这个背景下，我们重新审视“领域的边界”这个概念。
假如我们仍然使用之前的文章中提到的准则：“聚合之间不存在相互引用”，那么你设计出来的结果是不是就会像我们之前推演的那样，像下图一样：
如果你仍然有疑惑，我把具体的类图也添加进来，你是不是就一目了然了：
当然，现实是我们的科技并没有像上面设想的那样发达，我们最终还是要将模型数据存储到数据库的，因此，我们需要ORM框架来帮助我们解决模型的“存取”问题，注意这里我用到的是“存取”，不包含搜索，搜索的事情，我们可以用更加灵活的解决方案，这涉及到一种叫做CQRS的模式，这又是另一个故事了。
假如我们有一个很强大的ORM，可以帮助我们根据Id，取出模型，我们操作完模型，ORM再帮我们“Save”进数据库，我们不需要关心这里面它到底做了什么，那么是不是这个ORM也可以帮助我们摆脱“数据库知识”的诅咒，让我们在建模的时候专注需求和模型？
基于上面的推导，我认为有如下结论：
那么，你对上面的结论有什么看法？你在用什么样的ORM？你参与的项目的代码组织方式，是否让你可以专注业务？欢迎在文章评论区友善地讨论，也欢迎关注我的公众号（老肖想当外语大佬）以获得最新的更新。
下一篇，我将介绍一种能够在各个角色间建立共鸣的建模沟通方法，以使得我们的建模思维可以落地和复制，敬请期待。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。