There are several patterns for implementing Domain Logic or Business Logic:
1) Table Module – is an object, in a single instance, that processes business logic for all records in a database table, or a view.
2) Transaction script – organizes interaction with business logic through procedures that receive requests from the presentation layer.
3) Domain Model – directly, the object model of the domain, which includes both behavior and data.
These patterns are described in more detail by Martin Fowler, in his book The Architecture of Enterprise Software Applications. Enterprise Application Templates ”(P of EAA)). In this book, he shows that the first two patterns are more attractive at the beginning of working with the domain, but he also draws attention to the fact that when increasing the complexity of the domain logic, more attention should be paid to maintaining the infrastructure using the first two approaches, this time can be reduced if turn in your decision to the third of the above templates, the so-called “Domain Model”.
Based on this, we will draw a small conclusion that this template (“Domain Model”) is best suited, for example, for such a difficult area as the financial market. Most of the software created today is designed for various business needs, therefore, some abstract, generalized solutions find their place in the market (with quite high competition) less and less. DDD is not only a good design, but also a good example of how to highlight a domain in software in order to more easily overcome complexities, frequent changes, communication problems and other ailments of the domain, instead of developing an ugly one. a complex system to understand, in which any change or fix can unleash an avalanche of more and more defects on you.
