Hello , it is me again , we continue our series of Post about Patterns of Entreprise Application Architecture, indeed in this post we have talked about the domain layer , but the issue here is , okay i have a domain layer but how to organize well all this logic of the software i am building 😐 ?

Three Patterns

1. Transaction Script
2. Domain Model
3. Table Module

fine , talk me about them , be patient 😆 , let's start

Transaction Script Pattern

When i saw what is was about , i realize that i have already use that in many projects , here is the definition of the book :

A Transaction Script is essentially a procedure that takes the input from the presentation, processes it with validations and calculations, stores data in the database, and invokes any operations from other systems. It then replies with more data to the presentation, perhaps doing more calculation to help organize and format the reply

i know , you are a software developer , the explanation will be better with code , so i will not create a new wheel , here is the explanation with code.

Now , I hope that you have seen that it is all about a script or function that handles a single transaction or use case of the software. 😉

however like M. Fowler says

Sadly, there are also plenty of disadvantages, which tend to appear as the complexity of the domain logic increases

Domain Model Pattern

Here is another the Pattern that solves complex logic , the domain model pattern , with the object oriented way. M. Fowler says in the book :

With a Domain Model we build a model of our domain which, at least on a first approximation, is organized primarily around the nouns in the domain. Thus, a leasing system would have classes for lease, asset, and so forth. The logic for handling validations and calculations would be placed into this domain model, so shipment object might contain the logic to calculate the shipping charge for a delivery. There might still be routines for calculating a bill, but such a procedure would quickly delegate to a Domain Model method.

Here is the Code 😏

Now because the business logic has increased , we now have Objects and each objects handle the logic that is relevant to it 😃 .

It has so many advantages , however it comes with a cost 😩

The costs of a Domain Model (116) come from the complexity of using it and the complexity of your data source layer. It takes time for people new to rich object models to get used to a rich Domain Model. Often developers may need to spend several months working on a project that uses this pattern before their paradigms are shifted

Table Module Pattern

This the third pattern , and if you have done a little bit of Spring i can assure you that you have already used it. What is the main philosophy behind this :

At very first blush the Table Module looks like a Domain Model since both have classes for contracts, products, and revenue recognitions. The vital difference is that a Domain Model has one instance of contract for each contract in the database whereas a Table Module has only one instance.

Before going further look at the code

My understanding of this pattern is that , it is tightly coupled with your datasource(database) , and this is why M. Fowler says :

However, you can’t use a number of the techniques that a Domain Model uses for finer grained structure of the logic, such as inheritance, strategies, and other OO patterns.

Yeah , i know PostgreSQL is a powerful database , but sorry we can not implement the Strategy design Pattern in our database 😁

yeah, yeah , you are actually sating to yourself that there is three ways to handle domain logic , how can i choose the right pattern for the right project ? 😐

Making A Choice

M. Fowler presents in the book a beautiful diagram , to deal with our thoughts for handling domain logic

I truly thing that the first step to choose , is to know the pattern for solving a problem and then we can choose , i will finish with this sentence of the book

The good news is that I can say that you should use a Domain Model whenever the complexity of your domain logic is greater than 7.42. The bad news is that nobody knows how to measure the complexity of domain logic. In practice, then, all you can do is find some experienced people who can do an initial analysis of the requirements and make a judgment call.

you think i was going ? no i am there to finish with a concept i think which is very helpful to know and it is called service layer pattern

Service Layer

It is a Layer that is above your domain layer and it is the only layer that draw a path between the presentation layer and the domain layer , but if your project uses transaction script pattern it is not necessary , but if you go with a domain model , i think it is a good pattern to grasp.

M. Fowler :

A common approach in handling domain logic is to split the domain layer in two. A Service Layer is placed over an underlying Domain Model or Table Module. Usually you only get this with a Domain Model or Table Module since a domain layer that uses only Transaction Script isn’t complex enough to warrant a separate layer. The presentation logic interacts with the domain purely through the Service Layer, which acts as an API for the application.

😇 I will not leave you like that the code is here

Bye , see you next time , keep coding 😍 and enjoy learning 😉 .