I'm studying about API.
I saw a design pattern with these layers:
I found the AppServices and DomainServices layers unnecessary. For me the ideal would be to create only one layer of Services where my entire business rule would be OR in the API itself to be contained the rule.
I would like to know if I am wrong, or if the image design pattern is the best way ...
One thing I've learned is that there is no one design pattern that fits all cases. Going a little to extremes, if your application should only add two numbers, creating 5 different projects (Services, Infra, App, etc) is simply exaggeration.
These divisions we create have one and only one goal: to organize code. Think of them as drawers. That piece of code I'm writing now deserves the trouble of getting another drawer?
The number of divisions in your application should be proportional to the complexity of the domains covered.
I agree with Genos, everything will depend on the complexity of your project and your scenario.
The ideal is to have as few layers as possible, that is, only the required number of layers.
Separating in layers, in addition to organizing the code we are making that group something reusable in another context, imagine that one day you want to implement a new application for that same domain of the API. With the domain in a separate project we can simply refer you to the new application.
To help us think about how we separate, a link from Uncle Bob who wrote the Clean Code book is interesting too.
I'll give you a hint of how you might have thought of this organization, which seems to me to be a SOA application:
But to know, just looking at the code.
If you are still unable to understand a proposed layer pattern, simply do not use it. It's no use just putting N layers if you do not understand why each one exists.
There's a KISS concept (Keep it simple, stupid), I'm not calling anyone stupid, it's the concept. Translating is keep it simple. Watch this talk by a StackOverlflow employee, it's in Portuguese. You will see the simplicity behind this site. Simplicity often caters.
In most cases the simple MVC pattern that comes by default in an ASP.NET solution will suit. In your case of an API, you will not have the Views, but you would not need to create layers unless it is extremely necessary, and if you can not identify if it is necessary, then do not.
Focus on delivering functionality to the client securely and well, at least by following the basic principles of object-orientation such as separation of responsibility and #.
Take this pattern of layers, and try to develop something for testing, so you can learn and understand, but do not do something that will be sold or put into production with something you do not master.
