Domain Driven Architecture

One problem with early versions of opentaps is that the ofbiz framework which we used is not an object-oriented framework. Instead, it is based on a data model which is fundamentally relational, and that data model is accessed via a map-like Java Object called GenericValue. Most of the services in the business tier used a GenericDelegator to retrieve GenericValues from the database, performed operations on them, and then stored them back into the database again using the same GenericDelegator.

While this lightweight architecture could do a lot of things, as opentaps grew it became apparent that some of the application could significantly benefit from an object-oriented architecture. A few months ago, we started down this path and thought about how to write more object-oriented code with the ofbiz framework. More recently, after reading about Domain Driven Design and Domain Driven Design Quickly, we realized that what we really needed was not just object-oriented code, but rather a more formal classification of our business tier into domains. This document explains what domain driven architecture is, how we have implemented it, and how it could help you structure your code.

What is Domain Driven Design?

The basic idea behind a domain is that it is used to group together all the "domain expertise," or business knowledge, of an application and separated from the application and its infrastructure. It is a different way of thinking about how to organize large software applications and complements the popular Model View Controller (MVC) architecture, which we also use in opentaps. With the Model View Controller architecture, the application's user interface (View) is separated from its business logic (Model), and a Controller directs requests from the view layer to the relevant business logic found in the model layer. The advantage of doing this is that the same business logic could then be reused elsewhere, either in another view layer page or as part of some other more complex business logic in the model layer.

MVC, however, doesn't really say how your model should be structured. Should it be object-oriented, or should all be written in procedure languages or even SQL? Should they reside in separate components and packages, or could you just have one big file, which has all of your business logic? The domain driven design answers this question by separating the model layer ("M") of MVC into an application tier, a domain tier, and an infrastructure tier. The infrastructure tier is used to retrieve and store data. The domain tier is where the business knowledge or expertise is. The application tier is responsible for using the infrastructure tier to obtain the data, then consult the domain tier to see what should be done, and then use the infrastructure tier again to achieve the results.

For example, let's say that you wanted to assess late charges on all of your customers' outstanding invoices. MVC would tell you that your application should have a screen which shows you a list of outstanding invoices, and when the user says "Assess Late Charges", the controller would pass the users' input parameters to business logic in the model tier to do the dirty work of assessing those late charges.

With a domain driven design, we would look more deeply at what that dirty work actually involved. The application tier would call upon the infrastructure tier to retrieve all the invoices which should may get assessed charges. Then, it would present that list of invoices to the domain tier, which has the business expertise to say "Should this invoice get charged?" and if so "How much should this invoice get charged?" The domain tier would then return the late charges for each invoice to the application tier, the application tier would then called on the infrastructure tier again to store the late charges into the database.

Why Domain Driven Design?

Why do we want to do all this?

The first and most obvious benefit of domain driven design is that it helps us organize our application into natural domains, so you don't have to come in contact with all the 800+ tables in opentaps and the over 1,200 services that support them. For example, a domain driven design would allow us to break an application down into a few large domains, such as Customer, Order, and Invoice, and hide all the details within each of those domains, such as all those tables related to each customer, order, and invoice, from developers who don't need to work with them. Thus, if you are working on the Order domain, you may need to know a little bit about a Customer, such as his home address, shipping addresses, payment methods, but you don't really need to know all the tables used to track the relationship of customer information and their histories.

A related advantage is that it allows us to separate business tier expertise from infrastructure expertise. Thus, if you are working primarily with implementing business processes, you can write code, which basically retrieves data from the different domains, processes them, and return the results of your business process. You can leave the handling of the database to an expert whose job is to work on the infrastructure tier, and who's probably relieved not to have to worry about your business processes.

A subtle but potentially more valuable advantage, however, is that domain driven design gets us closer to a plug-and-play application. Imagine again that your application is broken down into the Customer and Order domains, so that the Order domain interacts with customer information only through the Customer domain. What if you wanted to use the opentaps order entry and order management tool with another CRM application, be it SugarCRM or SalesForce.com? If you had a good domain separation, it would be a matter of just implementing the Customer domain objects used by the Order domain to call the new CRM application. Alternatively, if you wanted to use opentaps CRM with a legacy order management system, you could simply implement the Order domain objects used by the Customer domain in opentaps.

Finally, by separating out the domain tier of business knowledge from the infrastructure tier, it also allows us to deploy opentaps on a different infrastructure tier later as well. For example, instead of using the entity engine, you could use Hibernate or even the Google storage API instead. This frees your application from lock-in to a particular framework.

Terminology

Before looking at implementation, let's look at some of the terminology used by Domain Driven Design, which will serve as our starting point:

• Domain is a body of business expertise. For example, you might have a domain of all business expertise about customers -- who is responsible for them, what prices they should get, how to contact them, etc.
• Entity is an object which has a distinct identity. For example, a Customer has a distinct identity with an ID.
• Value Object is an object which has no distinct identity. For example, the color of a product does not have a distinct identity if you think the "blue" of two blue shirts are the same thing.
• Aggregate is a higher level entity which could be viewed from the outside and in turn links you to other entities and value objects. For example, Customer might be an aggregate, so you can view Customer from Orders, Invoices, etc., but a Customer's addresses and phone numbers should only be retrieved by going through Customer first.
• Infrastructure is where the lower level infrastructure of your application is available. For example, it would provide you with the ability to access databases, remote web services, etc.
• Factory is used to create Entities. For example, a Factory might create an Invoice entity (and its related entities and value objects) from an Order entity.
• Repository is used to retrieve, store, and delete Entities from the database. For example, a Repository might help you store the Invoice (and related entities) your Factory created and then bring them back from the database.

How Domain Driven Design is Implemented

Our implementation involved some compromises: we wanted to be true to the spirit of the domain driven design, but we also had to live with our existing framework and code base. What we have done is implemented a set of foundation classes in org.opentaps.foundations. to support the Entity, Repository, Inrastructure, and Factory concepts under the ofbiz framework. Then, we will go through and implement the key domains in each application as domains. For example, we have started with org.opentaps.financials.domains.invoice to implement the Invoice domain and its related Repository and Factory.