You are building a system that keeps track of Companies. Those companies have Contacts. Those contacts are often specialists that only answer certain types of questions, such as Billing/Payment, Sales, Ordering, and Customer Support.
Using Domain Driven Design and an Onion Architecture, I've modeled this with the following types:
- Has Contacts
- Has Contact Types
- ContactType (enum)
- CompanyRepository (interface)
- EFCompanyRepository (defined in an external assembly, uses EntityFramework, implements CompanyRepository)
Our team has a split opinion on how to model the database for this application.
Side A: The Lean DDDers:
- It's the job of the Domain to define which ContactTypes are valid for a Contact. Adding a table to the database to validate that unknown ContactTypes are not saved is a sign of a leaky domain. It spreads logic too far out.
- Adding a static table to the database and corresponding code is wasteful. In this application the database solves one problem: persist the thing and give it back to me. Writing an extra table and corresponding CRUD code is wasteful.
- Changing the strategy for persistence should be as easy as possible. It is more likely to change that business rules. If I decide that SQL Server costs too much I don't want to have to rebuild all the validation I put in my schema.
Side B: The Traditionalists [that's probably not a fair name. The DBCentrists?]:
- It's a bad idea to have data in the database that doesn't make sense without reading code. Reports and other consumers have to repeat the list of values themselves.
- It's not that much code to load your db type dictionaries on demand. Don't worry about it.
- If the source of this is code and not data I will have to deploy bits instead of a simple SQL script when it changes.
Neither side is right or wrong, but one of them is probably more efficient in the long run, counting development time for initial development, bugs, etc. Which side is it - or is there a better compromise? What do other teams writing this style of code do?