In Chapters 5–7, where we discussed business logic in detail, you learned four differ‐ ent ways to model business logic: the transaction script, active record, domain model, and event-sourced domain model patterns.

Both the transaction script and active record patterns are better suited for subdo‐ mains with simple business logic: supporting subdomains or integrating a third-party solution for a generic subdomain, for example. The difference between the two pat‐ terns is the complexity of the data structures. The transaction script pattern can be

used for simple data structures, while the active record pattern helps to encapsulate the mapping of complex data structures to the underlying database.

The domain model and its variant, the event-sourced domain model, lend themselves to subdomains that have complex business logic: core subdomains. Core subdomains that deal with monetary transactions, are obligated by law to provide an audit log, or require deep analytics of the system’s behavior are better addressed by the event- sourced domain model.

With all of this in mind, an effective heuristic for choosing the appropriate business logic implementation pattern is to ask the following questions:

• Does the subdomain track money or other monetary transactions or have to pro‐ vide a consistent audit log, or is deep analysis of its behavior required by the business? If so, use the event-sourced domain model. Otherwise...

• Is the subdomain’s business logic complex? If so, implement a domain model. Otherwise...

• Does the subdomain include complex data structures? If so, use the active record pattern. Otherwise...

• Implement a transaction script.

Since there is a strong relationship between a subdomain’s complexity and its type, we can visualize the heuristics using a domain-driven decision tree, as shown in Figure 10-3.

Figure 10-3. Decision tree for business logic implementation pattern

We can use another heuristic to define the difference between complex and simple business logic. The line between these two types of business logic is not terribly sharp, but it’s useful. In general, complex business logic includes complicated business rules,

invariants, and algorithms. A simple approach mainly revolves around validating the inputs. Another heuristic for evaluating complexity concerns the complexity of the ubiquitous language itself. Is it mainly describing CRUD operations, or is it describ‐ ing more complicated business processes and rules?

Deciding on the business logic implementation pattern according to the complexity of the business logic and its data structures is a way to validate your assumptions about the subdomain type. Suppose you consider it to be a core subdomain, but the best pattern is active record or transaction script. Or suppose what you believe is a supporting subdomain requires a domain model or an event-sourced domain model; in this case, it’s an excellent opportunity to revisit your assumptions about the subdo‐ main and business domain in general. Remember, a core subdomain’s competitive advantage is not necessarily technical.