DDD 是如何落地到数据库设计的

最新推荐文章于 2025-01-11 10:36:16 发布

程序员笑武

最新推荐文章于 2025-01-11 10:36:16 发布

阅读量1.2k

点赞数 13

文章标签：数据库 oracle 语言模型人工智能自然语言处理知识图谱 .net

本文链接：https://blog.csdn.net/m0_59164304/article/details/142768803

版权

引言

想象一下，你是个盖房子的建筑师（现在咱们暂时把开发架构师比作建筑师）。你先搞清楚客户想要什么，再画图纸，最后才是找个靠谱的施工队给你开工。同样，DDD（领域驱动设计）就是软件开发中的“设计图纸”，先用它搞清楚业务需求，再落地到数据库设计上去。

那么问题来了：DDD 那么高大上的理念，和“油腻”数据库能有什么关系？

别急，我们今天就从 DDD 的角度出发，看看它是怎么把优雅的设计落地到数据库这个“搬砖”现场的。

一、领域模型 VS 数据库模型：两条平行线？

DDD 的核心思想是：「业务逻辑要比技术实现更重要」。说白了，就是搞清楚业务是什么，然后再谈代码怎么写，数据库怎么设计。

「领域模型」：这是一个在代码中反映业务的模型，强调的是业务行为、规则和约束。比如，订单的状态流转、付款逻辑等。
「数据库模型」：这个就简单了，咱们最熟悉的东西——表、字段、外键、索引，搞好性能，存好数据。

听上去，两者好像完全不搭边。一个是站在云端的业务逻辑，一个是脚踏实地的数据表设计。我们该怎么让这两条平行线交汇在一起？

二、从聚合到表设计：你画我改，我改你看

聚合（Aggregate）是 DDD 中的一个关键概念，它是领域模型的核心。简单来说，聚合就是一组强相关的对象，这些对象在业务逻辑上是一个整体。

举个例子，假设我们正在设计一个“电商系统”的订单聚合模型。订单不仅仅是“订单表”，它还和商品、支付信息等有强关联。于是，我们的聚合根是**「订单」**，它负责管理订单相关的业务逻辑和数据。

那聚合和表的设计有什么关系呢？

「聚合的边界确定表的关系」
订单聚合内部的对象，可以通过订单 ID 作为外键关联，比如订单表、订单商品表、支付表。这就决定了数据库表之间的外键关系和连接方式。
「聚合根与事务一致性」
订单聚合中的多个对象，在业务上通常要保持一致性，比如订单创建时需要同时生成支付信息和商品明细。如果你用的是关系型数据库（比如 MySQL），那这些信息可以放在同一个事务中操作，保证数据的一致性。如果用的是 NoSQL 数据库，比如 MongoDB，你可能会考虑把这些数据放在同一个文档里。

三、如何用领域事件处理数据库的“慢热”

数据库处理业务时，有时候动作是“慢热型”的，比如创建订单后，发货、更新库存这些事情并不需要立即完成。此时，领域事件就可以登场了！

「领域事件是什么？」
领域事件是领域模型中的“广播站”，它告诉系统中的其他模块：“嘿，我这边有重要事情发生了，你们需要做点什么！”。比如，订单创建成功后，会发出一个“订单已创建”的事件，其他模块比如发货系统、库存系统就能收到并做后续处理。
「领域事件如何影响数据库设计？」
在数据库设计上，领域事件通常意味着我们需要一个**「事件日志表」**来记录这些事件。如果你使用事件溯源（Event Sourcing）架构，所有的领域事件会记录下来，数据库里不再存储订单的当前状态，而是通过事件重放来还原订单的状态。

四、如何避免贫血模型：业务逻辑与数据库解耦

在 DDD 中，强调领域模型应该有丰富的业务逻辑，不能只是数据的搬运工。而在传统的数据库设计中，往往会出现所谓的“贫血模型”：数据库的表和领域模型基本一一对应，业务逻辑分散在各个地方，比如 service 层和 controller 层，领域模型仅仅存储数据，没有行为。

「如何避免这种情况呢？」

「实体负责自身逻辑」
在领域模型中，实体对象应该尽量负责自身的业务逻辑，而不是把这些逻辑丢给 service。比如，订单实体应该包含“确认收货”的方法，而不是简单的 getter/setter。
但是，在数据库中，你还是得把订单的状态流转设计好，比如用 status 字段来表示订单的状态，确保每次更新时能正确反映业务逻辑。
「防腐层的作用」
DDD 中还强调使用“防腐层”（Anti-corruption Layer），它能帮我们在领域模型和数据库模型之间建立一个适配层，避免领域模型被数据库设计“侵蚀”。举个例子，防腐层可以通过 DAO 层或者 Repository 层，保持领域模型的清晰，同时用数据库做最合适的存储设计。

五、性能与扩展性：聚合与分库分表的博弈

当系统变得复杂，用户增多时，数据库性能问题就开始浮现了。尤其是涉及到大表时，你可能需要用到**「分库分表」**的策略。而这又跟 DDD 的聚合模型产生了博弈。

「分库分表的挑战」
当你把订单数据拆到不同的表或者数据库中时，订单聚合内的事务一致性就变得不再简单。比如，你的订单数据和支付数据分到了不同的数据库中，那在业务上需要保证它们一起成功或失败就变得很棘手。
「分布式事务的支持」
解决这个问题的办法就是使用分布式事务管理，比如基于 Seata 或 TCC（Try-Confirm-Cancel）模式，来确保分库分表后的聚合仍然能保持事务的一致性。数据库设计上，需要为这些分布式事务保留一些额外的状态字段或者日志表。

如何学习大模型 AI ？

由于新岗位的生产效率，要优于被取代岗位的生产效率，所以实际上整个社会的生产效率是提升的。

但是具体到个人，只能说是：

“最先掌握AI的人，将会比较晚掌握AI的人有竞争优势”。

这句话，放在计算机、互联网、移动互联网的开局时期，都是一样的道理。

我在一线互联网企业工作十余年里，指导过不少同行后辈。帮助很多人得到了学习和成长。

我意识到有很多经验和知识值得分享给大家，也可以通过我们的能力和经验解答大家在人工智能学习中的很多困惑，所以在工作繁忙的情况下还是坚持各种整理和分享。但苦于知识传播途径有限，很多互联网行业朋友无法获得正确的资料得到学习提升，故此将并将重要的AI大模型资料包括AI大模型入门学习思维导图、精品AI大模型学习书籍手册、视频教程、实战学习等录播视频免费分享出来。

在这里插入图片描述