The Blog of Matt Peters

Note: This is part of my series on Domain Driven Design:

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.

Note: This is part of my series on Domain Driven Design:

Today I conclude my series on Domain Driven Design. In the first part we looked at a brief introduction and the concept of Entities. In the second part we covered Value Objects and Services. Today we’ll look at Repositories and Factories.

Repositories and Factories

Eventually, when defining your Domain language, you are going to have to interact with the data stores and/or back end systems. This is where Repositories come into the picture. A Repository is meant to translate the data from the user identifiable Domain Language into the format needed for the data store, and then to perform the operations needed to send it there.

I will create an interface for each Entity that needs to be stored using a repositories. So, we have a Reservation Entity, I’ll have an interface called the IReservationRepository. It will define all of the CRUD operations. Then, for each datastore, I’ll create a repository class that implements one or more of these interfaces. We may have the SqlServerRepository that implements IReservationRepository, ILocationRepository, etc. The piece that ties this together is the Factory.

I’ll create a factory called the RepositoryFactory that has a method called GetReservationRepository that returns an IReservationRepository. It looks in a configuration file to get the correct class (the SqlServerRepository) that needs to be created and returned to be used as the IReservaitonRepository.

So, what does all of this buy us? Let’s say that today you are storing your reservations in a database, but tomorrow you need to store them in some other type of back end system. You create a new repository implementing the interface and modify your configuration file and you are up and running with the now data store. Or, if you want to write unit tests using a mock repository that doesn’t hit an actual database that is easy to do as well.

Conclusion

So, this has been a brief overview of Domain Driven Design. I have found this to be a very useful tool when designing systems as it fits in cleanly with the rest of our user-centric methodology and gives you a concise framework that can be used to architect anything from the most simple application to the very complex.

There are two books that I would recommend for those that want to dig deeper into the subject. Those books are:

• Domain-Driven Design: Tackling Complexity in the Heart of Software by Eric Evans
• Applying Domain-Driven Design and Patterns: With Examples in C# and .NET by Jimmy Nilsson

Note: This is part of my series on Domain Driven Design:

Today’s post is a continuation of my series on Domain Driven Design. One of my favorite parts of Domain Driven Design is how it narrows your focus down to a handful of design patters that will work for just about any application you are building. I discussed the first of these design patters in the last post, the Entity. This is the most important pattern for building out your ubiquitous domain language. The next pattern to discuss is the Value Object.

Value Objects

Just like Entities, Value Objects have attributes. The difference between them comes in the way that you identify them. An Entity has a unique ID and is identified by the ID. For example, an employee has an Employee ID number. A Reservation, as we discussed in the last post, has a Reservation Number. Entities can always be identified by a unique ID.

Value Objects, on the other hand, contain a collection of attributes, and it is those attributes that define the object. Value Objects are immutable, that is they cannot be modified after they are created.

Examples of Value Objects in the car rental application would be the pickup date / time. This date / time object would have a month, day, year, hour and minute associated with it. There is no separate unique ID to identify it as it is defined by the the collection of its attributes. If you modify one of those attributes, it is a completely separate date / time object. On the other hand, if you modify one of the attributes of a Reservation (for example, the Car), you have modified the Reservation but the reservation itself is the same.

So, the easiest way to think of the separation between Entities and Value Objects is to determine if it has a unique ID or if it’s identity is fully defined by the sum of it’s attributes.

An interesting thing to consider is the Rate object that I discussed in the last post. A Rate has a price, a location, and a vehicle. Is this an Entity or a Value Object? Normally I would probably say that it is a Value Object, because if you change one of those attributes, you have changed the quoted Rate. However, having worked at a rental car company, I know that they assign IDs to quoted rates and store every quoted rate in the database. So it is persisted indefinitely and is referred to by the unique ID. So, I believe a case could be made for it either way.

Services

So far we have talked about methods that are applied directly to Entities or Value Objects. But, what if you have a method that does not naturally fit there? An example would be a GetRates that takes the pickup location, pickup date and return date, and returns a list of available rates. Where does this method go? This is where a Service comes in. You would create a RatesService that contains this method.

An important characteristic of services is that they are stateless. That is, the RatesService takes some values as input, performs an operation, returns a result, and then goes away. This would be a good candidate for static methods in most languages.

In Domain Driven Design these services are treated as first class citizens along side the Entities as you are mapping out your domain language. Users can clearly think of a RatesService that you throw information into and gives you meaningful results.

In the next post I will discuss the last two design patterns used in Domain Driven Design: Repositories and Factories.