数据库中的领域模型可以成为可持续的解决方案吗？

我刚开始担任新职位，是一家基于Microsoft技术的中小型公司的数据库开发人员。我很早就注意到关于最佳实践，设计模式，测试和项目管理的实践与我在学校所教的有多少不同。

最让我烦恼的是我们的主要数据库开发人员（以下称“约翰”）如何将模型架构保留在数据库中！为此，我们有3个“魔术”表；一种用于数据库方案，一种用于表，一种用于列。

将记录插入“ 表 ”表中（通过数据库触发器）会生成实际的对应表。在“ 行 ”表中插入一行会用该行更新引用的表。反过来，他的自制C＃程序会读取这些代码以生成C＃模型，前端开发人员将其用于控制​​器和外部。

除此之外，大多数开发都是根据ASP.NET MVC框架完成的。

我发现这种方法存在一些缺陷：

• 我们需要他维护ORM，而他很少有时间这样做（工作安全性很好！）
• “表”和“行”表的触发器存在缺陷。它们不支持表更新，也不支持检查约束或更多“高级”功能。虽然我们可以肯定地改进它们，但我不确定这是否可行。
• 将程序逻辑保存在数据库中感觉很奇怪且很严格（尽管可以通过C＃扩展他的模型）。
• 他的C＃模型生成器必须由3个人之一（我是其中之一）手动运行，并且还不成熟，无法包含在自动化构建过程中。

一些人建议逐步使用像Entity Framework这样的经过测试的真实产品，但他不予理,，并声称将业务逻辑保留在代码层中仅适用于小型应用程序和启动项目。

这篇文章导致了一些看起来像是经过深思熟虑的讨论，但这并不是我的意图。我只想对我们的体系结构方法进行一些说明。

将域模型保留在数据库中是否可以成为成长中的公司的可持续解决方案？

您正在描述内部平台。

内部平台的问题在于，您需要重新发明平台或技术（在本例中为关系数据库）的所有机制，这些机制在数十年的发展和努力中得到了磨练和完善，但是却没有很好地重新发明。您将绕过选择较传统设计的人员可以使用的所有优化，而将最初的简单性和高雅性换成了将来的复杂性和艰辛性。

就是说，如果此过程的最终产品是真实的表和真实的类，它们为真实的业务域对象建模，那么除了工具的不成熟性之外，我认为这种方法没有太大的危害。Stack Exchange实际上使用他们自己的本地ORM，这似乎已经为他们解决了。因此，我知道这类“山寨”方法是可行的。

请注意，大多数采用“表优先”方法的ORM都只是查看数据库中的表结构来创建类。您的朋友创建的“表”和“行”表仅仅是大多数现代关系数据库系统的系统表中已经存在的元数据。

进一步阅读
“ Vision”项目，这是有关内部平台效应的警示性故事
_{（您可以跳过前言，并在“ Introducing Vision”小标题下开始阅读）}