Implementation

Each procedure is implemented as a simple, straightforward procedural script. It can use a thin abstraction layer for integrating with storage mechanisms, but it is also free to access the databases directly.

The only requirement procedures have to fulfill is transactional behavior. Each operation should either succeed or fail but can never be in an in-between state. If a process fails for some reason, the system should remain consistent—hence the pattern’s name, transaction script.

Here is an example of a transaction script that converts batches of JSON files into XML files:

DB.StartTransaction();
 
var job = DB.LoadNextJob();
var json = LoadFile(source);
var xml = ConvertJsonToXml(json);
WriteFile(destination, xml.ToString();
DB.MarkJobAsCompleted(job);
 
DB.Commit()

Applicability Context

The transaction script pattern is well adapted to the most straightforward problem domains, where the business logic resembles simple procedural operations. For example, in extract-transform-load (ETL) operations, each operation extracts data from a source, applies transformation logic to convert it into another form and loads the result into the destination store. This process is shown in Figure 5-2.

Figure 5-2. Extract-transform-load data flow

The transaction script pattern naturally fits supporting subdomains where, by definition, the business logic is simple — supporting subdomains. It can also be used as an adapter for integrations with external systems — generic subdomains, or as a part of an anticorruption layer (more on that in Chapter 9).

The main advantage of the transaction script pattern is its simplicity. It introduces minimum abstractions and minimizes the overhead both in runtime performance and in understanding the business logic. That said, this simplicity is also the pattern’s disadvantage. The more complex the business logic gets, the more it’s prone to duplicate business logic across transactions, and consequently, inconsistent behavior — when the duplicated code goes out of sync. As a result, transactions should never be used for core subdomains, as this pattern won’t cope with the high complexity of a core subdomain’s business logic.

The simplicity of the transaction script earned it a dubious reputation. Sometimes, the pattern is even treated as an anti-pattern. After all, if a complex business logic is implemented as a transaction script, sooner than later it’s going to turn into an unmaintainable big ball of mud. It should be noted, however, despite the simplicity, the transaction script pattern is ubiquitous in software development. The next three business logic implementation patterns that we are going to discuss in this and the next two chapters, all include a transaction script -- either implementing the business logic, or as orchestrator for other components carrying out the business logic.

Implementation

Consequently, this pattern uses dedicated objects to represent complicated data structures: active records. Apart from the data structure, these objects also implement data access methods for creating, reading, updating, and deleting records—the so-called CRUD operations. As a result, the active record objects are coupled to an object-relational mapping (ORM) or some other data access framework. The pattern’s name is derived from the fact that each data structure is “active”; i.e., it implements data access logic.

As in the previous pattern, the system’s business logic is organized in a transaction script. The difference between the two patterns is that in this case, instead of accessing the database directly, the transaction script manipulates active record objects. When it completes, the operation has to either complete or fail as an atomic transaction:

public class CreateUser {
 public void Execute(userDetails) {
  try {
    DB.StartTransaction();
 
    var user = new User();
  user.Name = userDetails.Name;
    user.Email = userDetails.Email;
    user.Save();
  DB.Commit();
    } catch {
      DB.Rollback();
  throw;
      }
    }
  }

The pattern’s goal is to encapsulate the complexity of mapping the in-memory object to the database’s schema. In addition to the persistence responsibility, the active record objects can contain business logic, for example, validating new values assigned to the fields or even implementing business-related procedures that manipulate an object’s data. That said, the distinctive feature of an active record object is the separation of data structures and behavior (business logic). Usually, active records’ fields have public getters and setters that allow external procedures to modify the active record’s state.

Applicability Context

Since, essentially, an active record is a transaction script that optimizes access to databases, this pattern can only support relatively simple business logic such as CRUD operations which at most validate the user’s input.

Accordingly, as in the case of transaction script, the active record pattern lends itself to supporting subdomains, integration of external solutions for generic subdomains, or model transformation tasks. The difference between the patterns is that active record addresses the complexity of mapping complicated data structures to a database’s schema.

The active record pattern is also known as anemic domain model antipattern. Or, in other words, an improperly designed domain model. I prefer to restrain from the negative connotation of the words “anemic” and “antipattern.” This pattern is a tool. Like any tool, it can solve problems, but it can potentially introduce more harm than good when applied in a wrong context. There is nothing wrong with using active records when the business logic is simple. Furthermore, using a more elaborate pattern when implementing simple business logic will also result in harm by introducing accidental complexity. In the next chapter, you will learn what a domain model is and how it differs from active record.

Note: It’s important to stress that in this context “Active Record” relates to the design pattern and not the “Active Record” framework. The pattern name was coined in Martin Fowler’s book “Patterns of Enterprise Applications Architecture”. The framework came later as one way to implement the pattern. In our context, we are talking about the design pattern and the concepts behind it, not a specific implementation.