扫码阅读
手机扫码阅读
DDD 中的多对多关系建模
266 2024-08-28
我们非常重视原创文章,为尊重知识产权并避免潜在的版权问题,我们在此提供文章的摘要供您初步了解。如果您想要查阅更为详尽的内容,访问作者的公众号页面获取完整文章。
查看原文:DDD 中的多对多关系建模
文章来源:
TechLead 少个分号
扫码关注公众号
多对多关系的挑战与解决方法
文章讨论了多对多关系在软件建模中的难点及其对软件架构可能造成的问题。在一个具体项目例子中,作者经历了用户与空间间多对多关系管理的困难,发现这种关系导致权限管理复杂且业务需求难以满足。
传统数据库模型的限制
传统的数据库设计使用中间表来处理多对多关系,如项目中的"workspace_user_relation"表。然而,这种设计在技术实现和业务支持上均存在不足。例如,它难以管理用户权限,管理员的权限限制,以及中间表的语义不明确。
面向对象与关系数据库的鸿沟
关系数据库理论自1969年提出以来,它的集合论基础在数据处理上有独特优势,但是与面向对象的编程模型存在天然鸿沟。对象关系映射(ORM)软件试图解决这一问题,但多对多关系在面向对象中是一个难以处理的“隐藏模型”。
重新思考多对多关系
作者提出使用主体-客体思维来重新思考多对多关系。通过识别出“隐藏的模型”,如“工作空间-用户”,并为其命名(例如“空间成员”),可以将复杂的多对多关系简化为两个一对多关系,从而清晰化模型。
隐藏模型的归属问题
在解决了命名问题后,还需决定隐藏模型的归属。以“标签”系统为例,可以设计通用的标签系统,或者将标签与具体业务关联。这取决于业务重点和对聚合搜索能力的需求。
结论
模型建立需服务于业务需求。业务人员需要明确业务重心,并在模型设计中做出权衡和取舍。
想要了解更多内容?
查看原文:DDD 中的多对多关系建模
文章来源:
TechLead 少个分号
扫码关注公众号
TechLead 少个分号的其他文章
为什么工程师都需要一块白板
一家靠谱的软件公司的墙面上都有许多写字的白板,越是专业的软件公司,越会使用白板来进行讨论。白板甚至是一种文化,越来越多的公司在办公室提供可以写字的墙面和容易擦写的马克笔。
系统设计 | 领域模型中的拓展点设计
如何为领域模型设计一些拓展点,应对多样化场景?
建模和编程中的契约 —— Design By Contract
1. 业务是生意,不是功能也不是交互,人是生意的主体。\x0a2. 人是不可靠的,需要用契约来约束生活的方方面面。\x0a3. 把软件组装起来的连接点就是接口,接口也是契约。\x0a4. 开发软件是关于生意的生意,管理团队也需要契约。
多对多关系解耦的数学原理
在面向对象设计中,多对多关系都是非常麻烦的问题。在现实中,我一般会根据经验让团队避免使用多对多关系。怎么从数学上看待这个问题呢?
系统设计 | 如何表达迭代技术方案?(战术篇)
本文整理了一些日常项目上进入迭代前的技术方案输出物。
加入社区微信群
与行业大咖零距离交流学习
软件研发质量管理体系建设
白皮书上线