Note: This is part of my series on Domain Driven Design:
- Part 1: Introduction and Entities
- Part 2: Value Objects and Services
- Part 3: Repositories and Factories
- Using Domain Driven Design with a Three Tiered Architecture
One of the questions I received related to the topic of Domain Driven Design was related to how we implement DDD in a three tiered architecture. The key to this is with the Repositories and Factories.
Let’s take for instance a website that consists of a web front end, a middle tier, and a database. The customer comes to the website and saves an order. The web front end will create the Order entity and populate it with the information submitted by the user. It will then call the RepositoryFactory to determine what Repository to use to save the Order. In the config file, it is specified that MiddleTierRepository should be used to implement IOrderRepository. So, the Factory returns the MiddleTierRepository and the web front end calls SaveOrder on it. This Repository calls a web method in the middle tier called SaveOrder.
The middle tier then receives the Order. It performs an type of validation upon it and decides to save it. It calls the same RepositoryFactory used above, but in its config file it is specified that SqlServerOrderRepository should be used in this instance to save the Order. So, the Factory returns the SqlServerOrderRepository, which also implements IOrderRepository, and calls SaveOrder on it to save it to the database.
We do use an ORM tool in this environment. We use nHibernate. So, in the situation above, we would use NHibernateOrderRepository instead of SqlSeverOrderRepository for the middle tier to save the order to the database.
In a nutshell, that is how we translated these patterns into a three tiered architecture.