Despite the large number of application design approaches, two main ones stand out:

  • Transaction Script
  • Domain Model

The first is simple and allows for conveniently organizing code into separate procedures that process external requests. However, as application logic becomes more complex, spreading it across many procedures leads to code duplication and other issues. Furthermore, mixing database interaction with logic processing complicates unit testing and reduces code reliability.

On the other hand, using a Domain Model at the start often seems like over-engineering, adding significant code without guaranteeing freedom from errors. However, in the long term, this approach enables the creation of programs with complex domain logic without an exponential increase in complexity.

So, What to Choose?

What should you choose when starting an application, especially when its future usage and scale are uncertain? It’s a difficult decision, but you can combine both approaches without compromise.

Let’s examine the similarities and differences between the two approaches.

Differences and Commonality

Application Layer

The application layer, hosting application services with functions implementing use cases, is quite similar to the Transaction Script approach. The main difference is that service functions contain no domain logic, unlike script procedures. This is not a major issue; at the initial stage, placing primitive domain logic there—while a violation of DDD principles—will not cause significant problems.

Infrastructure

Another issue is whether the script contains logic for database and infrastructure interaction. It is better to avoid this from the start, as it complicates testing, mixes responsibilities, and is generally poor practice. Even in the Transaction Script approach, it is good practice to isolate infrastructure interaction in a separate application layer.

Domain Layer

As mentioned, you can initially leave domain logic in the application layer. As it becomes more complex, you can move it to a separate layer and encapsulate it within domain entities.

Summing Up

Thus, an uncompromising solution is possible. You must separate infrastructure from logic and implement dependency inversion so that application logic does not depend on infrastructure. This is a small price to pay for the ability to easily transition from Transaction Script to DDD later, ensuring a quick start and manageable complexity growth.