Business logic is the most important part of software. It’s the reason the software is being implemented in the first place. A system’s user interface can be sexy, and its database can be blazingly fast and scalable, but if the software is not useful for the business it’s nothing but a technology demo.
In the first part of this report, we saw how important it is for all stakeholders to communicate in the ubiquitous language and to have a shared understanding of the problem domain. The system’s source code should also “speak” the ubiquitous language, and be designed according to the shared model of the business domain. But how do we implement it in such a way?
As we saw in Chapter 2, not all business subdomains are created equal. Different subdomains have different levels of strategic importance and complexity. In this chapter, we will examine four different ways of implementing business logic in code: the transaction script, active record, domain model, and event-sourced domain model patterns. Each pattern suits a different level of complexity in the business domain.
Transaction Script
This pattern is well adapted to the simplest problem domains, where the business logic resembles extract-transform-load (ETL) operations—i.e., 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-1.
Figure 5-1. ...
Become an O’Reilly member and get unlimited access to this title plus top books and audiobooks from O’Reilly and nearly 200 top publishers, thousands of courses curated by job role, 150+ live events each month, and much more.
