Organizing Domain logic

Avijeet Dash and Satyabrata Dash

We are still sifting through the narrative chapters from "Patterns of Enterprise Application Architecture". So we will be focusing more on the why domain model than how to implement domain model, which will be covered in our pattern section.

Domain models represent the entities and relationship between various entities within a specific business context. The business context is key to a domain and you can reuse the domain model anywhere in an enterprise application within the same business context. For example let’s say you are modeling an online stock trading application, so if your modeling is correct, then you should be able to reuse the domain model in any stock trading application with similar kind of business rules. Domain model is powerful because it allows handling the variation in business logic without having to rewrite the entire code.

Let’s consider the stock trading example more elaborately to understand the importance of domain model. The requirement definition of company X’s online stock trading application reads as "The customer should be able to buy/sell his stock only when he has sufficient funds in his account. " So you go ahead and write a Trade class as the following:

public void buyStock(Stock stock)

{

//Implementation for buying a stock

}

public void sellStock(Stock stock)

{

//Implementation logic for selling a stock

}

}

The class looks good only when it’s simple. Now Company X comes up with new requirements such as allow the user to trade in stock X if has 10% of the required money in his account, trade in stock Y if has 15% of the required money, provide price alerts to the user.

So what do you do then to handle this change? If you are following the above model, then you will go ahead and make the necessary changes in Trade class. The result is that you will have a bloated Trade class at the end of project with innumerable if else and other conditional statements and it’s will be too difficult for testing.

Now let’s find out how the domain model can help us from the above problems. Before we proceed to explain more on domain model, let’s figure out what other factors concern a software designer/architect.

You can handle all this complications becomes better, if you design your application as an object oriented domain model. Let’s take the stock trading application to analyze how domain model helps us.

Now we introduce a new entity called TradeStrategy and the Trade object defers all trading activities to TradeStrategy object. If you read GOF Strategy design pattern, then you will understand how the strategy pattern will now help here to model various variations in the business algorithms. So perhaps the TradeStrategy will delegate the buy and sell activities to BuyStockStrategy and SellStockStrategy concrete classes.

How does the above approach help us? It helps us in encapsulating the functionalities to specific classes and there will not be any bloated class that will handle all functionalities. It helps in managing the change lot better. So for example if we need any change to buy logic, then we will change the BuyStockStrategy and SellStockStrategy will be insulated from the change. This approach will ease unit testing, as it will be much easier to test the specific units of work.

Martin Fowler describes three patterns to store the domain logic.

We will briefly explain them here.

A Transaction Script is essentially a procedure that takes the input, performs all validations and computations and then persists the output in the database.

A Table Module organizes domain logic with one class per table in the database, and one instance of the class will contain various methods to manipulate the data. The primary distinction with Domain Model is Domain model has one instance per each record of the table, where as Table Module is organized to have one instance for the entire table.

We can have a fine-grained interface to domain model only if the client is local, which is unlikely in an enterprise application. So the common way to design the client interface would be to use Fowler’s Remote Façade pattern or J2EE Design Pattern’s Session Façade pattern.

Also read our Business Delegate, Value Object, Value Object Assembler and Composite Entity patterns to read about handling of distributed clients in J2EE projects.

The domain model is powerful although it requires more work upfront to design the entire model. The extra work pays off in the end when we get more and more complicated business logic and when we have to manage the change in business requirement quite frequently. We will talk more about various implementation strategies of domain model when we discuss about specific patterns in our upcoming articles.

Reference:

About Authors:

Avijeet Dash and Satyabrata Dash can be reached at avijeetd@yahoo.com and satyabrata_dash@yahoo.com respectively.