Despite the rather large number of different approaches to the application’s design, two main ones can be distinguished:
- Transaction Script;
- Domain Model.
The first of them is pretty simple and at the same time allows you to quite conveniently organize your code in the form of separate procedures that process external requests, but when the application logic becomes more complex, spreading it between a large number of procedures leads to code duplication and other undesirable consequences. And besides, if the work with the database occurs in the same place as the logic processing, it becomes difficult to use unit tests, and this also does not add reliability to your code.
On the other hand, using the domain model at the beginning of writing an application looks like an over-complication, since it adds quite a lot of additional code, and in itself does not protect against errors and problems. But in the long term, this approach allows you to create programs with rather complex domain logic without leading to an exponential increase in complexity.
So what to choose
What to choose at the beginning of work on the application, especially in a situation where it is not at all clear whether someone will use it and what will be its scale after 3 years of development? A difficult moment, but you can try to combine the two approaches and not compromise.
So, let’s look for similarities between the two approaches. And of course, let’s pay attention to the differences.
Differences and commonality
Application Layer
Let’s start with the fact that the application layer, which hosts application services with sets of functions that implement use cases, is quite similar to the Transaction Script approach. The main difference is that there is no domain logic in service functions, unlike script procedures. But this is not a big problem, and at the initial stage, placing primitive domain logic there, although it will be a violation of the DDD principles, will not lead to significant problems.
Infrastructure
Another issue is whether the script contains the logic of working with the database and other infrastructure systems. It is better to avoid this from the very beginning, as it complicates testing, mixes responsibilities, and simply looks bad. But in this case, even for the Transaction Script approach, it would be good practice to isolate interaction with the infrastructure in a separate layer of the application.
Domain Layer
As I already mentioned, at the start, all the domain logic can be left in the application layer, and then, when it becomes more complicated, you can take it to a separate layer and wrap it in the domain entities.
Summing up
So, an uncompromising solution is possible. Yes, in any case, it will be necessary to separate the infrastructure from the rest of the logic and have a little bother with dependency inversion so that the application logic does not depend on the infrastructure, but vice versa. But this is all a small price to pay for the ability to later easily turn Transaction Script into DDD, getting a quick start of work on the application and a linear increase in its complexity in the future.
1 Comment
Cool!