The area of responsibility of the service layer?

Good day, I can not understand the area of responsibility of the service layer, what he should know and what shouldn't? The Internet is too synthetic examples. For example, this: https://m.dotdev.co/design-pattern-service-layer-w...
Then the service class is named as the action - `createCouponService` and called its method make(), is that right? It seems to me that it would be correct to do CouponService::create(), and along with the create() to create and other techniques related to coupons, or am I wrong? In the example of the author is so that the service solves one small problem, namely the creation of the coupon, and it's like he knows nothing about the "external context", but it takes instance CreateCoupon expanding Request, is that right? Perhaps there right, but what if we want to work with an existing coupon (or any other entity), which shall then make the service in his methods, ready-made model (but the controller seems to be not to accept to work with the model) or query parameters? Or the entire query? Can't understand what the service layer should know and what not... And Yes, how true:

Coupon::doSomeOne();
Coupon::doSomeTwo();
Coupon::doSomeThree();


or

CouponDoSomeOne::do();
CouponDoSomeTwo::do();
CouponDoSomeThree::do();


And can be controller calls various services within a single operation, using, for example, conditional operators, or is it business logic, and should be calling only 1 method service, which in itself already will do the rest? What is a service? The class that contains the business logic relating to particular entities, or-as in the example, just issued from the controller code?
April 3rd 20 at 17:46
2 answers
April 3rd 20 at 17:48
Solution
Your misunderstanding of the application service layer is not your problem, and the problem of the concept of layers. Because the layer is a subjective and abstract concept, not related to the business rules which we are trying to automate the application. In fact, due to the ephemeral nature of the concept, examples with layers of flimsy, explanations are vague, and the layers are often the cause of disagreements in the team.

In order to design a competent OOP applications, it is sufficient to master the principles of SOLID. It is an objective of the design principles classes. which are difficult to interpret in two ways.

In the framework of solid, all what do you mean by service layer - it's just classes that perform some task. It does not matter what. The main thing that each class has minimal dependencies and most of the time performs one task. The idea of layers and services will cease to haunt the imagination, if you stop using the suffix "Service" in the title classes. This, ultimately, will force you to give classes names based on the tasks they accomplish.

Also please note that it is not a replacement to conventional design approaches, such as, for example, patterns or DDD. Concentrating on the design of the classes taken separately, the solid is quite compatible with the other principles.

And about how to do better

Coupon::doSomeOne();
Coupon::doSomeTwo();
Coupon::doSomeThree();


or

CouponDoSomeOne::do();
CouponDoSomeTwo::do();
CouponDoSomeThree::do();


you can answer that:
  1. in class names have no place verbs (Do .- it's a verb)
  2. the class must conform to the principles of SOLID


If both these conditions are true, then you are on the right track.

Do not worry if not immediately entered in what I wrote here. All these tops require practice. In fact, so programming and design are disciplines requiring high qualifications.
In order to design a competent OOP applications, it is sufficient to master the principles of SOLID

It depends on what you mean by "master". Most of the stops on memorizing definitions.

Minimum learn to design if you can imagine what adherence to SOLID principles is affected.
The concepts of Coupling/Cohesion in modules, dependency elimination.

Regarding the PLO it is important to understand the difference from procedural programming, and that by doing the getters and setters in the models we turn her into an object and into a data structure, returning essentially to a procedural style. - jon86 commented on April 3rd 20 at 17:51
@jon86, and yet many come to the combination of DDD and ADM, and don't get bogged down only in DDD. - delia_Towne86 commented on April 3rd 20 at 17:54
@delia_Towne86,
and yet, many come to the DDD and the combination of ADM and not only go to DDD.

Or do you think that come to DDD.
In General, DDD very broad topic, and closer to the process than to code I in the above comment did not mention not to mention want for password. - jon86 commented on April 3rd 20 at 17:57
April 3rd 20 at 17:50
Solution
The business logic does not need to be removed from the entity (preferably an entity was not clogged rendering logic and getters of all sorts).

Services can be all sorts of senders of emails, gatway to the external API, etc.
I could be wrong, but in my opinion you are fundamentally wrong, and described how to do. Let's see what others say, they were deeply mistaken. - Elena44 commented on April 3rd 20 at 17:53
@Elena44, to Study architecture in the Toaster a little short - sighted. To relearn to do things properly longer you.
Take books Bob Martin / Fowler, find trusted sites on the topic / source material.

Just Laravale is an important issue - the use pattern, Active Record, due to the fact that it offers combines and the interaction with the database and business logic(by definition). This approach is suitable only for small applications.

If you laravale models will leave only the data, you will receive a Table Data Gateway.

Essence is the most important part in the system by definition. Not a layer to the DB and the domain layer if you want layers. Here is a little about the classification https://martinfowler.com/bliki/EvansClassification.html

The imposition of logic in the services is a recognized anti-pattern - https://martinfowler.com/bliki/AnemicDomainModel.html - jon86 commented on April 3rd 20 at 17:56
@Elena44,
I mean specifically the pattern Service Layer and its application in Laravel, but not a free interpretation

Specifically pattern here.
Read on, make sure that should not be in the services of any business logic. Maximum - challenge models with BL. - jon86 commented on April 3rd 20 at 17:59
@jon86, for a reference thanks! Esteemed, and understood that I know nothing :) - Elena44 commented on April 3rd 20 at 18:02
@Elena44, not Much buries immediately. AR/Anaemia and anti-pattern which is very widely used, most likely you will be with her and her supporters frequently encounter on projects.
To properly design the system is very difficult, and we need to understand the criteria of complexity, as opposed to just sculpt a new service for each feature.

It pays off if your project grows and needs to scale development, but often the project simply do not have people able to promote and implement such ideas. This I mean that it is often better to do "how" than the Internet, I am writing to say "good"(even if it is objectively and universally good), because without experience/understanding will be even worse. - jon86 commented on April 3rd 20 at 18:05

Find more questions by tags OOPLaravel