Enterprise systems usually have multiple layers. From top to bottom they are: presentation layer, business logic layer, and persistence layer. The middle layer—business logic represents the core of the application where all of the business processes and decisions take place.

The requirements for the business logic layer tend to change more often than the requirements for the rest of the application. We might be lucky when we get a complete specification, but that happens rarely. Even then, the requirements usually evolve over time and are often re-worked. As this happens, a standard solution using imperative style language (imperative programs are a sequence of commands for the computer to perform; for example, languages such as Java and C#) would quickly end up with so-called spaghetti code—lots of nested if-else statements.

There is no well defined way of representing the business logic in Java or C#. What usually happens is that every application represents business logic differently.

For example, consider the following code that does some checking on customer level, customer accounts, and account balance:

if (customer.getLevel() == Level.Gold) {
    //do something for Gold customer
} else if (customer.getLevel() == Level.Silver) {
    if (customer.getAccounts() == null) {
        //do something else for Silver customer with no accounts
    } else {
        for (Account account : customer.getAccounts()) {
            if (account.getBalance < 0) {
                //do something for Silver Customer that has
                //account with negative balance
            } 
        }
    }
}

Code listing 1: Code written in standard Java (or any imperative style language).

First, the code checks if the customer is a Gold level customer and does something, then it checks if the customer is a Silver level customer, and if so, it checks if this customer has no accounts and does something in this case. If the customer has accounts, the code performs some logic for each account that has negative balance.

The point of this Java 'spaghetti code' is to give you an idea what we are trying to prevent. You may think that it doesn't look that bad. However, after a couple of changes in requirements and developers that are maintaining the code, it can get much worse. It is usually the case that if you fix one bug, you are more likely to introduce five new bugs. A lot of requirements are literally packed into a few lines of code. This code is hard to maintain or change in order to accommodate new requirements.

As more conditions are added, the performance of this system will degrade. Moreover, when we want to change the behavior of the application, we'll have to re-compile and re-deploy the whole application.

It is not only difficult to represent business logic in a imperative programming style language, but also hard to differentiate between code that represents the business logic and the infrastructure code that supports it.

For developers, it is hard to change the business logic. For domain experts, it is impossible to verify the business logic and even harder to change it.

There is a need for a different paradigm for representing the business logic.