From a practical point of view, how can you adapt the domain model to the MVC pattern? For example, could I use some wrapper classes?
Share
Sign Up to our social questions and Answers Engine to ask questions, answer people’s questions, and connect with other people.
Login to our social questions & Answers Engine to ask questions answer people’s questions & connect with other people.
Lost your password? Please enter your email address. You will receive a link and will create a new password via email.
Please briefly explain why you feel this question should be reported.
Please briefly explain why you feel this answer should be reported.
Please briefly explain why you feel this user should be reported.
From a practical point of view, how can you adapt the domain model to the MVC pattern? For example, could I use some wrapper classes?
They aren’t really related.
MVC is a design pattern for separating the concerns of storing data (model), presenting various views of the data (view), and interacting with that data (controller). While it may be a “design” pattern, it is really about the design of code. The views are usually, but not necessarily used for GUIs.
Domain-Driven Design is a style of designing software where you focus on modeling the domain to create a shared well-understood model of the problem domain – a “domain model”. Domain-Driven design is not just “design”, but also represented in the code, requirements, conversations amongst various stakeholders, etc.
So, you wouldn’t really “adapt” one to the other, though you certainly can implement MVC using objects from your domain model. For example, if you modeled a BankAccount entity and wrote a corresponding class for it, you could use that as the model in an MVC triad. Perhaps the controller handles depositing and withdrawing cash, and several views (for example a debit, credit, and summary view) are updated upon model change. There are multiple flavors of MVC, and depending on what you pick you may end up modifying your domain model. For example, you could use the observer pattern where your views are notified whenever a model entity changes. This does mean you would be mixing non-domain concepts (observer registration, notification, etc.) into your domain object. It may be better to wrap the domain object in this case to keep a clean separation between the domain model and presentation layer, if that’s important to you. Perhaps that is what you mean by “adapting” one to the other.