In the last post, we talked about the different models that co-exist in an application. However, some of these models may or may not exist in a given application and time. To get a better understanding of this effect, let’s review 3 different configurations and the way they affect the application models mentioned before.

Transaction script

A transaction script as described by Martin Fowler, it’s a procedural (often a structured programming) approach to organize an application logic. It contains all the steps to fulfill a request/use case/scenario/story. In my experience, this kind of applications often uses the persistence model directly. This means that this model doesn’t have a domain model but the business logic is embedded in the transaction script itself. Often the transaction script returns a different model on the result, effectively using a presentation model.

Table module

A table module is a different way to organize an application. It’s based on the idea of having a structure that represents a table, just one row at a time. The object itself it’s just an access mechanism to the data of the underlying table. It allows to move to any given record and provides access to all of its fields. You can put the business logic onto this object making it instantly available to all of the records. Often this object is directly bound to the controls of the UI. This means that the persistence, domain and the presentation model are exactly the same.

Domain model

A domain model centric configuration works by separating the domain layer from anything else. The resultant objects are focused on one thing and one thing only: hosting the business logic and rules. By doing this (keeping the domain model ignorant to persistence and presentation needs) we are forced to create a persistence and presentation model. This may initially closely resemble the domain model but can change independently to accommodate the needs of the layer it belongs to (presentation, persistence). Usually, the domain model is developed using an OOP paradigm, whereas the persistence model is often developed under a RELATIONAL paradigm (if using a relational DB) and the presentation model is done following an ACTION or OBJECT representation approach.

Closing thoughts

So there you have it. Go and check your codebase again. Which pattern it follows? Can you pinpoint the different models being used? leave your comments below…