2.5 KiB
What domain models are not!
What problem were domain models there to solve? Back in the day, we had layered architecture with a business layer. The business rules (first name shouldn't be longer than 10 characters) were spread all over the place. Patterns of Enterprise Application Architecture was written and everyone got excited about the Domain Model pattern. Domain Model pattern was contrasted against Active Record, Transaction Script, etc. Domain Model sounded so great. Who wouldn't want a domain model in their system? Just like agile. Who would not want to be agile?? A domain model follows the rule of component driven development. They expose properties, methods and events. There are clear boundaries to a component. Context of domain model was to be "if you have complicated and ever-changing business rules". Meaning...this pattern was not meant to be used for everything!!! Not meant to manage all of data access. Domain model is supposed to be independent of all other concerns. For example, UI concerns should not enter in. DB concerns also. Communications also! They are only simple, stand-alone components. No direct or indirect coupling. They are to made up of POCOs. Domain Models are NOT entity relationships! Domain model is supposed to handle complex and ever-changing rule. Products always have names. Orders always have products. Customers always names and phone numbers, etc. If we have those types of objects we don't have a domain model! This was its problem, the name. It made people think that just about any collection of objects is a domain model. These types of classes ended up getting all sorts of reasons to change, violating the single-responsibility principle. Unit tests became overly-familiar with the internals of the domain model and kept breaking. When you are following the domain model appropriately...
You could deploy it anywhere.
You can have more than one domain model! Nowhere does the definition say you have to have a single model that covers everything in your domain! Logic in the DB can fit a specific set of problem. Specifically when you need to do operations on huge amounts of data. The DB handles that best. Why are we moving 20GB of data to a server to process 20KB of logic and then just put the 20GB back into the database? You CAN mix patterns. You may need a domain model pattern here, a transaction script pattern there and the active record pattern somewhere else.