Can domain models in the database be a sustainable solution?

Question

I just started at a new job as a database developer for a medium-small sized, company based on Microsoft-technology. I noticed early on how much practices deviate from what I've been taught at school regarding best practices, design patterns, testing and project management.

What is bugging me the most is how our main database developer (henceforth called "John") keeps the model schema in the database! We do this by having 3 "magic" tables; one for database-schemas, one for tables and one for columns.

Inserting a record into the "Tables"-table generates (through a database trigger), the actual, corresponding table. Inserting a row into the "Rows"-table updates the referenced table with that row. These are in turn read by his homemade C#-program to generate C# models, which are used by the frontend-developers for controllers and outwards.

Apart from this, most of the development is done according to the ASP.NET MVC framework.

I see a couple of flaws with this approach:

• We need him to maintain the ORM, and he rarely has the time to do so (job security is good!)
• The The triggers for the "Tables" and "Rows" table are flawed. They don't support table updates, nor Check-constraints or more "advanced" features. While we could surely improve them, I am not yet sure if this is the way to go.
• Keeping the programmatic logic in the database feels weird and restrictive (although it is possible to extend his models through C#).
• His C# Model-generator has to be run manually by one of 3 people (among which I am one), and is not yet mature enough to be included into an automated build process.

Several people have suggested phasing in a true and tested product like Entity Framework, but he dismisses it, claming that keeping the business logic in the code-layer is only suitable for small-scale applications and bootstrap projects for startups.

This post is leading towards something that could look like a opinionated discussion, but that is not my intention. I just want some clarification regarding our architectural approach.

Can keeping the domain models in the database be a sustainable solution for a company in growth?

Answer 1

You're describing an Inner Platform.

The problem with inner platforms is that you reinvent all of the mechanisms of a platform or technology (in this case, a relational database) that have been honed and perfected over decades of evolution and effort, but re-inventing it poorly. You're bypassing all of the optimizations that are available to those who choose a more conventional design, and trading initial simplicity and elegance for future complexity and hardship.

That said, if the end product of this process is real tables and real classes modelling real business domain objects, I don't see much harm in this approach, apart from the immaturity of the tools. Stack Exchange actually uses their own, homegrown ORM, and that seems to have worked out for them. So I know that these kinds of "cottage" approaches can work.

Note that most ORM's that take the "table-first" approach simply look at the table structure in the database to create the classes. The "table" and "row" tables that your friend has created is merely metadata that already exists in the system tables of most modern relational database systems.

Further Reading
The "Vision" project, a cautionary tale about inner platform effect
_{(You can skip the preamble and start reading at the subheading "Introducing Vision")}