Domain Driven Design : Making Implicit concepts Explicit

In the previous post, I discussed about how to query the domain objects. That post completes the issues with domain object lifecycle management. In this post, I will discuss how to make implicit concepts explicit in order to make domain model more expressive

Sometimes small details of the design get lost in the code. We tend to consider small business rules and constraints as implicit and these details are not given enough importance as they should be given.They are often coded as a bunch of if-else blocks in the code and this makes the identification of these business rules difficult and more importantly makes design less effective. Let see some of the concepts/design patterns which can be used to make these implicit concepts more explicit.

Domain Driven Design : Querying Domain Objects

After having discussed about object creation in the previous post, I would like to discuss the challenges of querying objects in a domain model.

There is a well designed domain model with a rich set of associations between objects. How to get to a particular entity or value object inside the domain model? Since the domain model is well connected, if you have a reference to a root entity, you can get to the other members to which this root is associated. But, how to get to this root? Well, we can have a global root which contains the collections of all the root of the entities. For example, in a sales order application, you can have a global root containing the collection of order and customer objects.

One drawback of the above solution is that it will perform badly in a distributed system. For example, when a client asks the global root to return the list of customers, and there are millions of customers, we have to do a database query and it will return millions of records. This will cause a lot of data transfer on the network. With multiple clients, this solutions would not work at all.

In most situations, you would need only a subset of customers which meet a particular set of conditions. So, what are the options that we have to return a subset of customers to the client in a way which performs well and does swamp the domain model with the complexity of the query logic. The options that we have are

Domain Driven Design : Creating Domain Objects

In one of the previous posts, I discussed about Aggregates and their design considerations. In this part of the series, I will discuss the issues in object creation with domain objects.

The normal way of creating an object by it’s client is via it’s public constructor. This works well with a simple objects. But, when complex objects like Aggregates are concerned, their construction can be complex and the process of creation can become overwhelming for an object to handle. As part of it’s construction, an aggregate might have to

• create local entities within an aggregate.
• check the invariant logic before adding a local entity.

Object creation has nothing to do with the domain. Moreover, with complex object creation, an object tends break the Single Responsibility Principle(SRP). So, it is recommended to separate the object creation logic from the object. In Domain Driven Design(DDD), a program element whose primarily responsibility is to create complex domain objects and aggregates is called a Factory. Ideally, a factory should create the product atomically with all the safety checks, that is, with the all the invariants applied appropriately.

Domain Driven Design : Aggregates

Every object has a lifecycle. Some objects take birth and die in a single method while others have a more complex and longer life. Typically, Domain Objects falls into the second category. The lifecycle of a domain object is shown below

As the lifecycle of a domain model is complex, it is advisable to separate the domain logic from the lifecycle management logic. Furthermore, sometimes, grouping related objects to manage them as an entity is easier than managing each of them separately. Domain Driven Design(DDD) suggests to group related objects as Aggregates and to use Factories and Repositories to manage the lifecycle of the object. In this blog, I will discuss about the Aggregates and their design considerations.

Domain Driven Design : Expressing Concepts

Object oriented analysis and design(OOAD) is essentially an activity to model a system as an interaction between objects. Each object, which is an instance of a class and has state and behaviour, represents an entity with in the system. These entities invoke other entities to perform certain activities and are often associated with each other to model a system. Domain driven design(DDD) recommends guidelines which tend to optimize/enhance the process of identifying entities and defining relationship between them. It advocates to classify objects as Entities and Value objects based on certain criteria, to model Services, which abstract behaviour which is not specific to a particular entity, to divide application into Modules, and to minimize and constrain Associations between objects. In this blog, I will discuss these recommendations.

Domain Driven Design : An Introduction

Introduction

The primary purpose of most software projects is to add value to the customer’s business. This is done by abstracting the complex web of thoughts inside a human mind in the form of a software program. Most software projects cater to a particular domain, and in many software projects, the domain of a software project is not technical. Unfortunately, majority of the technical people do not give enough importance to the domain of the software, and hence, they lack the required domain knowledge. This lack of domain knowledge leads to a situation where What(to do?) takes over Why(to do?). Generally, in such a scenario, it might be possible to deliver a usable product, but the primary purpose of adding business value is often neglected.

The above mentioned situation is quite common and there is a continual influx of thoughts, which intend to provide a solution, by various experts. Eric Evans is one of such experts, who based on his experience, gained by working on complex projects, epitomized his findings in the form of tips, suggestions, patterns and guidelines, and coined a term Domain Driven Design, better known as DDD. In this blog, I intend to present various aspects of DDD and how it suggests to tackle the complexity of the domain.

Organizing Domain Logic

Introduction

Most enterprise applications use Layering as the primary technique to break the complexity of the software projects. Layering involves breaking down the applications in various layers where each layer lie above the other and provide services to the higher layer. Layering provides following benefits

• You can understand about a layer without knowing about other layers. For example, if you know how TCP works you can create your own FTP service without actually knowing about the internals of the ethernet.
• It is easy to substitute the layers with alternative implementation. For example, if DAO layer is designed properly, if should be easy to change the ORM solution from Hibernate to iBatis easily.
• Layering also helps in standardization and extensibility.

But the downsides of layering applications include cascading changes, performance overhead of converting data from one representation into another and it is not often easy to decide the later of a particular component. Considering the benefits of layering and it’s applicability to almost any sort of computer application, it is used widely and successfully.

Three primary layers of an enterprise application can broadly be categorized into

1. Presentation Layer: Information display, HTTP requests, command line invocations, batch API, etc.
2. Domain Layer: Here lies the “Heart of the software”
3. Datasource Layer: Provides access to external resources like databases, messaging, mail server, etc.

In this blog, we will discuss various patterns of organizing domain logic and specific pros and cons of each. We will also discuss how these approaches compare with each other.