According to Eric Evans, Domain-driven design (DDD) is not a technology or a methodology. It’s a different way of thinking about how to organize your applications and structure your code. This way of thinking complements very well the popular MVC architecture. The domain model provides a structural view of the system. Most of the time, applications don’t change, what changes is the domain. MVC, however, doesn’t really tell you how your model should be structured. That’s why some frameworks don’t force you to use a specific model structure, instead, they let your model evolve as your knowledge and expertise grows.
Domain-driven design separates the model layer “M” of MVC into an application, domain and infrastructure layer. The infrastructure layer is used to retrieve and store data. The domain layer is where the business knowledge or expertise is. The application layer is responsible for coordinating the infrastructure and domain layers to make a useful application. Typically, it would use the infrastructure to obtain the data, consult the domain to see what should be done, and then use the infrastructure again to achieve the results. Srini Penchikala explains this in more detail here: “Domain Driven Design and Development In Practice“.
Object-oriented programming is the most important element in the domain implementation. Domain objects are designed using classes and interfaces, and take advantage of OOP concepts like inheritance, encapsulation, and polymorphism. Most of the domain elements are true objects with both State (attributes) and Behaviour (methods or operations that act on the state). Entities and Value Objects in DDD are classic examples of OOP concepts since they have both state and behaviour.
Terminology used by Domain-driven design
- Entity: An object which has a distinct identity. For example, a User entity has a distinct identity with an ID.
- Value Object: An object which has no distinct identity, like numbers and dates. For example, if two Users have the same date of birth, you can have multiple copies of an object that represents the date 16 Jan 1982.
- Factory: Used to create Entities. For example, you can use a Factory to create a Profile entity from a User entity.
- Repository: Used to store, retrieve and delete domain objects from different storage implementations. For example, you can use a Repository to store the Profile your Factory created.
- Service: When an operation does not conceptually belong to any object.
The purpose of this post was to provide a brief introduction to Domain-driven design.
Part 2: Domain-Driven Design: Data Access Strategies
If you’re interested in learning more about Domain-driven design or Model-driven design, I recommend the following articles:
14 responses to “Domain-Driven Design and MVC Architectures”
Looking forward to the follow-ups – hopefully it’ll be interesting reading while waiting for my “Domain-Driven Design” book to arrive from Amazon =)
A nice DDD introduction, can’t wait to read upcoming posts relating it to the Zend Framework.
Also I’d like to recommend the free ‘Domain Driven Design Quickly’ book over at InfoQ. http://www.infoq.com/minibooks/domain-driven-design-quickly
Looking forward seeing your implementation.
Looking forward to your follow ups, I enjoyed listening to Deep Fried Bytes podcasts on DDD..
They might be a nice little introduction for people with a long commute etc.
Excellent. Thanks for the links Dave :)
IMHO the application layer maps well to the controller classes: a thin layer to manage user requests and act on the model.
[…] Domain-Driven Design and MVC Architectures fede.carg ( blog ) (tags: ddd) […]
A good summary of the book of Eric Evans: http://www.infoq.com/minibooks/domain-driven-design-quickly
I’m really interested in this stuff, can’t wait for the next part. :-)
[…] Domain-Driven Design and MVC Architectures A good overview on the development methodology. […]
[…] Domain-Driven Design and MVC Architectures – an introduction to the domain-driven concept and some definition of terms that he’ll be using. […]
Hi Raphael, your comment went to the spam queue. I don’t know how it got there, but it’s now live. Sorry about that.
[…] Domain-Driven Design and MVC Architectures […]
Im a bit confused – the application layer sounds a lot like the Controller in an MVC architecture?