"One Model to rule them all, One Model to find them,
One Model to bring them all in to the darkness and bind them"
The quote comes from the book "The Lord of The Ring" and like the characters in that book many are they in the developer community that awaits "the prrrecious", but I fear that they will wait forever. I firmly believe that "The prrrecious" will never surface in this time and age.
The notion of a model is not new to the software industry; for ages models have described our software. With the models, a simple truth has always been present; every model excels, at its piece of the puzzle. As an example, different parts of UML describe separate aspects of software and solve unique description challenges.
Although always present, this truth seems only to be attached to the description of software, not the implementation of it.
In the Microsoft developer community the introduction of LINQ, LINQ to SQL and the Entity Framework raised a question that has been debated heavily since; "Should I use relational models or domain models to represent my data?"
Another and a bit older question that is also heavily debated is; "Should I use message models or domain models to represent my entities?"
The answers to both the questions are the same; there is no "prrrecious" model, so don?t wait around for it. Instead, follow these two simple design principles:
Use the model that solves the immediate challenge the best.
Make sure that the transitions between different models are as smooth as possible.
This will guarantee that for each piece of your implementation puzzle you will get the best suited model.
In my opinion the relational model (tables, rows, columns and normalizations) are by far the most efficient way of storing information and ensuring its integrity. Domain models are by far the most efficient way of processing data and applying business rules in code. Messages and services excel in creating and sharing loosely coupled and highly agile processes across the enterprise(s).
This makes the different models complement each other, not exclude one or the other.
So therefore I propose that we all chant this mantra:
"I will use the right model for each piece of the software puzzle, even for the implementation"
More on Domain Driven Design: http://www.domaindrivendesign.org/
More on Service Design: http://msdn2.microsoft.com/en-us/skyscrapr/ms954638.aspx