系统设计 | 多对多关系模型拆解案例
版权声明
我们非常重视原创文章,为尊重知识产权并避免潜在的版权问题,我们在此提供文章的摘要供您初步了解。如果您想要查阅更为详尽的内容,访问作者的公众号页面获取完整文章。
TechLead 少个分号
扫码关注公众号
扫码阅读
手机扫码阅读
多对多关系拆解分析与模型设计
经验丰富的程序员通常避免使用多对多关系,因为这表明领域模型设计时可能丢失了重要概念。本文通过分析多对多关系的具体案例,提供了领域模型设计的参考资料,并采用 E-R 图来描述这些关系。
具体案例分析
- 订单和商品:多对多关系会丢失订单行的概念,而实际上应引用商品的快照而非商品本身。
- 群和用户:在没有群成员概念的情况下,生命周期管理复杂且某些业务实现困难,例如记录成员在群中的信息。
- 标签和文章:提供了两种拆解方案,一种是将关系设计为标签项,另一种是作为文章标签,取决于业务需求。
- 学生和老师:多对多关系可以拆解为课程和班级,以及学生每年的班级变化。
- 用户、角色和资源:在 RBAC 模型中,用户角色和权限的概念可以拆解多对多关系。
- 分销渠道和商品:可以设计分销商品来拆解多对多关系,并考虑分销商自身的属性和逻辑。
- 组织和用户:需要设计员工和身份概念来拆解复杂的多对多关系。
总结
多对多关系提示了隐藏模型的存在,通常通过添加隐藏模型可以拆解多对多关系。在更复杂情况下,需要找到合适的归属来确立微服务边界。多对多关系是系统设计的钥匙,帮助揭示隐藏的模型。
文章来源于公众号“DDD和微服务”,作者“少个分号”。如有内容错误,可通过微信(shaogefenhao)联系作者并有机会领取红包。欢迎收藏、转发本文。
TechLead 少个分号
TechLead 少个分号
扫码关注公众号
还在用多套工具管项目?
一个平台搞定产品、项目、质量与效能,告别整合之苦,实现全流程闭环。
查看方案
TechLead 少个分号的其他文章
技术管理 | 如何通过提案+评审取得团队共识?
用提案+评审的方式处理团队不同意见。
低质量的需求耽误高质量的工程师
错误的需求往往不会责备需求的提出方,因为互联网时代需要快速 \x26quot;试错\x26quot;,而纠正需求所产生的工作却落到了工程师头上。
个人提升 | 程序员学习英语的经验和教训
程序员学习英语的经验和教训
技术管理 | 从道德框架转变为利益框架
当你学会用“利益”而不是“好坏”去看人、看事,你会发现这个世界突然不那么让你愤怒了,甚至更容易谈合作、更容易做选择。与其生气别人“不讲良心”,不如问自己:“我能不能成为那个让别人必须考虑的人?”
建模和编程中的契约 —— Design By Contract
1. 业务是生意,不是功能也不是交互,人是生意的主体。\x0a2. 人是不可靠的,需要用契约来约束生活的方方面面。\x0a3. 把软件组装起来的连接点就是接口,接口也是契约。\x0a4. 开发软件是关于生意的生意,管理团队也需要契约。
加入社区微信群
与行业大咖零距离交流学习
PMO实践白皮书
白皮书上线
白皮书上线