Patterns of Entreprise Application Architecture : Organizing Domain Logic
Tags: architecture, software, domainlogic
Published: 2022-03-20 15:14:01

Hello , it is me again , we continue our series of Post about [Patterns of Entreprise Application Architecture](https://www.amazon.fr/Patterns-Enterprise-Application-Architecture-Martin/dp/0321127420), indeed in [this post](https://dev.to/edgaremmanuel/patterns-of-enterprise-application-architecture-layering-2k04) 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 :neutral_face: ? 


# Three Patterns
 
1. _Transaction Script_ 
2. _Domain Model_ 
3. _Table Module_

fine , talk me about them , be patient :laughing: , 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](https://java-design-patterns.com/patterns/transaction-script/).

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. :wink:

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](https://java-design-patterns.com/patterns/domain-model/) :smirk:

Now because the business logic has increased , we now have __Objects__ and __each objects handle the logic that is relevant to it__ :smiley: .

It has so many advantages , however it comes with a cost :weary:
> 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](https://java-design-patterns.com/patterns/table-module/) 

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](https://refactoring.guru/fr/design-patterns/strategy) in our database :grin:



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 ?  :neutral_face:


## Making A Choice 

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


![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/ph2keanmsl6w2qgil4y6.png)


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.

:innocent: I will not leave you like that [the code is here](https://java-design-patterns.com/patterns/service-layer/)


Bye , see you next time , keep coding :heart_eyes: and enjoy learning :wink: .