In the book Patterns of Enterprise Application Architecture by Martin Fowler two patterns are defined to handle business logic in the system. I do not think that much have changed since then. The IT industry evolved, but these patterns are still applicable to this day. I will unpack what those patterns mean and how they are applicable now.
Domain model is a pattern where object representing the model also contains the behavior and/or business rules in itself.
- ✔️ data together with the behavior
- ✔️ easy to extend
- ✔️ easy to comprehend / observe if applied correctly
- ❌ requires more effort and experience to implement
- ❌ may be overhead for a simple domain
Transaction script is a pattern where a separate script/object/function/service loads the data validates/modifies it and saves to the database.
- ✔️ requires less effort and experience to implement
- ✔️ fits simple domain applications
- ❌ anemic model, which is considered as an anti-pattern by a Martin Fowler
- ❌ hard to maintain / extend / observe on a more complex domain
Both of these patterns are pretty abstract and can be applied today with other architectural and design patterns. Each of those has pros and cons. You can use these pattern in your server side rendered UI MVC application with, react server components, PHP or Java server pages.
Difference
The difference between those patterns is complexity. Complexity of implementation, extensions and support. Domain model can harder to implement initially. But it reduces the complexity, when the model is evolving, getting more complex. Keeping business logic in one place with the domain reduces the complexity of extension and refactoring. On the other hand transaction script separates data from the behavior. At the start it is easier to model you data and write a transaction script to handle business rules. But this approach will not scale, with the size of your model and the domain complexity.
Challenges
At the time Martin Fowler wrote the book Patterns of Enterprise Application Architecture was written, the standard UI architecture was HTML rendered on server with a small amount of interactivity sprinkled by javascript. All logic could be handled by both patterns on the server. Mostly it is MVC pattern for a web server with a input controller acting as a mediator. Today the expectations of the UI/UX have changed. UI is way more interactive - UI applications handles routing, validation, data initialization and manipulation, UI flow management, security and whats not. Previously UI was not responsible for all those things. This is why implementing business logic in the maintainable manner is crucial for a modern UI application. Domain model is one of the options, which must be considered. If you will leave the majority of these concerns on the server, then UI will request those. Multiple requests will degrade the responsiveness of an application.
Examples
For example consider case when you need to validate the 1mb json data. You have thousands of business rules, which must be evaluated, to ensure the data is valid. During the data gathering process you will make thousands REST API calls to the server to validate the data, to provide instant feedback on entered values. If you will choose to make validation once per tab/dropdown/card/step, then user will have a bunch of errors after he completed the step. This can be a tradeoff of keeping the logic on the backend and requesting this logic from the server.
- using transaction script you will end up with thousands of functions, with duplicated logic between those and the code which is hard to comprehend.
- using the domain model pattern your business rules will be "managed" together with the model. Rules will be kept with the domain which matches the Single responsibility principle.
