前段时间,在工作中,我们不得不将主系统改为“跨rdbms”.我不确定这是否是正确的术语,但基本上系统只适用于MSSQLServer,但为了使新客户端成为可能,我们必须使系统能够同时使用MSSQLServer和Oracle.

由于原因,我们不使用ORM.相反,我们使用基于ADO的自定义数据访问层.

在此更改之前,我们对存储过程,数据库函数,触发器等进行了大量重述.数据库本身存在大量业务逻辑.

我们决定摆脱所有存储过程,触发器和东西,并基本上将数据库简化为仅仅存储层.

为了处理迁移,我们创建了一个.json文件,其中包含我们的数据库模式的表示：表,列,索引,约束等.创建了一个简单的应用程序来编辑该文件.通过使用它,我们可以编辑现有的表和列并添加新的表和列.

这个json文件在我们的存储库中进行了版本控制.执行应用程序时,例程读取文件,在内存中构建数据库的表示.然后,它从实际数据库中读取元数据,将其与内存中表示进行比较,并根据找到的差异生成脚本.

最后,执行脚本,更新数据库模式.

所以,现在是我真正的问题.添加新列时,开发人员需要：
– 向POCO类添加一个新属性,表示该表中的一行;
– 编辑将表列映射到类属性的方法,添加新的列/属性映射;
– 编辑处理数据库命令的类,创建一个指向新列的新参数.

最初实现此方法时,我考虑根据json文件中的更改自动生成和更新POCO类.这些将使类与数据库模式保持同步,我们不必担心开发人员在创建新列后忘记更新类.

这个功能实现起来并不严格,现在我对它有严重的怀疑,主要是因为我一直在研究清洁架构/洋葱架构和域驱动设计.

从DDD的角度来看,一切都应该是关于域的,而域反过来应该对它的持久性一无所知.

所以,我的问题基本上是：如何在不违反DRY和不使用“以数据库为中心”的方法的情况下保持我的域模型和数据库架构同步？

最佳答案 DDD将重点放在域语言及其在域类中的表示.数据库问题不是DDD的主要问题.

因此,如果打算应用DDD,则从数据库模式生成域类是错误的方向.

这个问题更多的是找到一种合适的方式来管理数据库升级,这与DDD几乎没有关系.基本读/写数据库操作的单元/集成测试可以帮助开发人员记住在更改数据库列时编辑所需文件.