Here we go again 😁

Organizig domain logic

In organizing domain logic I’ve separated it into three primary patterns: Transaction Script, Domain Model, and Table Module.

• 1️⃣ Transaction Script

It 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. The fundamental organization is of a single procedure for each action that a user might want to do. Hence, we can think of this pattern as being a script for an action, or business transaction. It doesn’t have to be a single inline procedure of code.

✅ Advantages

• It’s a simple procedural model that most developers understand.
• It works well with a simple data source layer.
• It’s obvious how to set the transaction boundaries: Start with opening a transaction and end with closing it. It’s easy for tools to do this behind the scenes.

❌ Disadvantages

there are also plenty of disadvantages, which tend to appear as the complexity of the domain logic increases. Often there will be duplicated code as several transactions need to do similar things. Some of this can be dealt with by factoring out common subroutines, but even so much of the duplication is tricky to remove and harder to spot. The resulting application can end up being quite a tangled web of routines without a clear structure.

• 2️⃣ Domain Model

With that 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.

🏁 Comparison Betwwen T. Script and D. Model

Explaining in sequance diagram the Transaction Script for a simple processing. (fig 2.1)

Sequence diagram explaining Domain Model for a simple processing. (fig 2.2)

In Figure 2.1, Transaction Script’s method does all the work. The underlying objects are just Table Data Gateways, and all they do is pass data to the transaction script. In contrast, Figure 2.2 shows multiple objects, each forwarding part of the behavior to another until a strategy object creates the results.

💯 Final Round

The value of a Domain Model lies in the fact that once you’ve gotten used to things, there are many techniques that allow you to handle increasingly complex logic in a well-organized way. As we get more and more algorithms for calculating revenue recognition, we can add these by adding new recognition strategy objects. With Transaction Script we’re adding more conditions to the conditional logic of the script. Once your mind is as warped to objects as mine is, you’ll find you prefer a Domain Model even in fairly simple cases.

• 3️⃣ Table Module

At very first blush the Table Module (125) looks like a Domain Model (116) since both have classes for contracts, products, and revenue recognitions. The vital difference is that a Domain Model (116) has one instance of contract for each contract in the database whereas a Table Module (125) has only one instance. A Table Module (125) is designed to work with a Record Set (508). Thus, the client of a contract Table Module (125) will first issue queries to the database to form a Record Set (508) and will create a contract object and pass it the Record Set (508) as an argument. The client can then invoke operations on the contract to do various things (Figure 2.3). If it wants to do something to an individual contract, it must pass in an ID. A Table Module (125) is in many ways a middle ground between a Transaction Script (110) and a Domain Model (116).

Sequence diagram displaying Table Module for a simple transaction. (Fig 2.3)

Conclusion for today

Once you’ve made it, your decision isn’t completely cast in stone, but it is more tricky to change. So it’s worth some upfront thought to decide which way to go. If you find you went the wrong way, then, if you started with Transaction Script (110), don’t hesitate to refactor toward Domain Model (116). If you started with Domain Model (116), however, going to Transaction Script (110) is usually less worthwhile unless you can simplify your data source layer.These three patterns are not mutually exclusive choices. Indeed, it’s quite common to use Transaction Script (110) for some of the domain logic and Table Module (125) or Domain Model (116) for the rest.

See you 😉