Business objects
I want to understand and discuss how beneficial the “Domain Model” (WEB-application architecture) (in particular, PHP) from a different point of view. What do you see in her disadvantages, advantages and what can be opposed to it.
A business object ( Business Object ) is an object in the OOP that represents an entity from a certain “domain”, that is, the industry for which the application is developed. For example, for an accounting program, objects can be:
Typically, business objects encapsulate data and complex logic, so the class interface practically reflects reality. Such an approach to programming is also called the “Domain Model” ( Domain Model ), and in opposition to it there is the ORM paradigm and Database-centric architecture and the whole approach to the development of architecture based on a technology rather than a business model.
Why do I use the Domain Model and do not use the Database-centric architecture and a similar approach?
Especially at the "topmost level." At the level of methods, there is no difference, usually a separate method of a business object is a rather complicated logic, such as making a payment or setting an auction rate, but even in this case there is no need to keep in mind something other than a specific problem (base structure, payment interface) systems).
')
In the application (in the controllers), everything looks visually and is read almost humanly:
$ payment = Payment :: makeNew ($ contractor, $ amount);
$ invoice = $ contractor-> lastInvoice ();
$ invoice-> markSettled ($ payment);
Who needs it? Imagine that after 2-3 months you needed to make changes, or a bug was discovered. The user will not tell you “I have a bug in the method that is responsible for payments. most likely it is related to the database. ” No, he will say "I do not pass the payment." And you know where to look for the problem (at least where to start - from the controller). And if he (the user) says: “I have the amounts in the accounts rounded incorrectly” again you know where to go - you don’t need to go to the controller - the point is in the method responsible for “total”.
This is especially beneficial when a new person comes to the project.
Of course, there is a nuance here - reuse can only happen if a new application is developed from the same “domain”. For example, a properly designed Invoice class is unlikely to need much change in a new application. Of course, the same is true for other approaches. Perhaps even more fully, however, if “utilitarian” classes are successfully developed, such as Profile, Form, Page are developed with a “Domain Model” (in this case, the “domain” is “WEB, Server Side Application”), their reuse will also be almost 100% and will not depend on the main, business domain.
The code turns out surprisingly "non-conflict", both from the point of view of a programming language, and from the point of view of a programmer as a person. Provided that all components are based on the Bussness Model. If, for example, you need to “cross” an auction and a store, then the Payment class will remain common to them, and the Product class will most likely become a “lot” for the auction. Class prefixes are needed only when you need to create a specific class, say FastshopProduct, while the associated classes will still accept an object of this class as a parameter if it inherits the Product and interact with it.
The problem here arises when you need to use third-party code. And most often you have to modify supporter classes so that everything is “smooth”.
Indeed, if classes, methods, and variables are called “humanly,” rather than somehow “user_data,” you rarely need to resort to comments in the code. And in general, I try not to overload the code with unnecessary comments. If the method returns an object of the Profile class, there is no need to write “the method returns a profile” —this is obvious.
If you really need - you can generate documentation based on the code. And in it, again, a novice can quickly figure out, because he will not be "flashed before my eyes" various BaseObject, BaseDbRow, user_data and all that. Knowing what the project (the “domain” of the project) is about is easier for a programmer to delve into the abstraction.
Of course, there is, as they say, in this barrel and a spoon. If each object encapsulates everything in itself, including the data (and this is the main distinguishing feature of this model), then, for example, when displaying search results, each object reads itself from the database itself, resulting in a page, depending on the situation, there may be a hundred and more requests. Personally, I do not see in this tragedy, with this, of course, you need to do something. Simple caching allows you to speed up everything in order.
A business object ( Business Object ) is an object in the OOP that represents an entity from a certain “domain”, that is, the industry for which the application is developed. For example, for an accounting program, objects can be:
- invoice (Invoice)
- payment
- contractor
- posting
Typically, business objects encapsulate data and complex logic, so the class interface practically reflects reality. Such an approach to programming is also called the “Domain Model” ( Domain Model ), and in opposition to it there is the ORM paradigm and Database-centric architecture and the whole approach to the development of architecture based on a technology rather than a business model.
Why do I use the Domain Model and do not use the Database-centric architecture and a similar approach?
The code is much clearer
Especially at the "topmost level." At the level of methods, there is no difference, usually a separate method of a business object is a rather complicated logic, such as making a payment or setting an auction rate, but even in this case there is no need to keep in mind something other than a specific problem (base structure, payment interface) systems).
')
In the application (in the controllers), everything looks visually and is read almost humanly:
$ payment = Payment :: makeNew ($ contractor, $ amount);
$ invoice = $ contractor-> lastInvoice ();
$ invoice-> markSettled ($ payment);
Who needs it? Imagine that after 2-3 months you needed to make changes, or a bug was discovered. The user will not tell you “I have a bug in the method that is responsible for payments. most likely it is related to the database. ” No, he will say "I do not pass the payment." And you know where to look for the problem (at least where to start - from the controller). And if he (the user) says: “I have the amounts in the accounts rounded incorrectly” again you know where to go - you don’t need to go to the controller - the point is in the method responsible for “total”.
This is especially beneficial when a new person comes to the project.
Code reuse
Of course, there is a nuance here - reuse can only happen if a new application is developed from the same “domain”. For example, a properly designed Invoice class is unlikely to need much change in a new application. Of course, the same is true for other approaches. Perhaps even more fully, however, if “utilitarian” classes are successfully developed, such as Profile, Form, Page are developed with a “Domain Model” (in this case, the “domain” is “WEB, Server Side Application”), their reuse will also be almost 100% and will not depend on the main, business domain.
No conflicts
The code turns out surprisingly "non-conflict", both from the point of view of a programming language, and from the point of view of a programmer as a person. Provided that all components are based on the Bussness Model. If, for example, you need to “cross” an auction and a store, then the Payment class will remain common to them, and the Product class will most likely become a “lot” for the auction. Class prefixes are needed only when you need to create a specific class, say FastshopProduct, while the associated classes will still accept an object of this class as a parameter if it inherits the Product and interact with it.
The problem here arises when you need to use third-party code. And most often you have to modify supporter classes so that everything is “smooth”.
The code is self-documented.
Indeed, if classes, methods, and variables are called “humanly,” rather than somehow “user_data,” you rarely need to resort to comments in the code. And in general, I try not to overload the code with unnecessary comments. If the method returns an object of the Profile class, there is no need to write “the method returns a profile” —this is obvious.
If you really need - you can generate documentation based on the code. And in it, again, a novice can quickly figure out, because he will not be "flashed before my eyes" various BaseObject, BaseDbRow, user_data and all that. Knowing what the project (the “domain” of the project) is about is easier for a programmer to delve into the abstraction.
Of course, there is, as they say, in this barrel and a spoon. If each object encapsulates everything in itself, including the data (and this is the main distinguishing feature of this model), then, for example, when displaying search results, each object reads itself from the database itself, resulting in a page, depending on the situation, there may be a hundred and more requests. Personally, I do not see in this tragedy, with this, of course, you need to do something. Simple caching allows you to speed up everything in order.
Source: https://habr.com/ru/post/55027/
All Articles