0
I’m studying about API.
I saw a design pattern with these layers:
I found the layers Appservices and Domainservices unnecessary. For me the ideal would be to create only one layer of Services where would be all my business rule OR in the API itself be contained the rule.
I wonder if I’m wrong, or if the image design pattern is the best way...
1
One thing I’ve learned is that there’s no design pattern that fits every case. Going a little to extremes, if your application should just add two numbers, create 5 different projects(Services, Infra, App, etc) is simply exaggeration.
These divisions that we create have one and only one goal: to organize code. Think of them as drawers. That piece of code I’m writing right now deserves the trouble of getting another drawer?
The number of divisions of their application shall be proportionate to the complexity of the areas addressed.
1
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 necessary.
Separating into layers, in addition to organizing the code we are making that group into something reusable in another context, imagine that one day you want to implement a new application for that same domain of the API. With mastery in a separate project we can simply reference it to the new application.
To help you think about how we separate follows a link by Uncle Bob who wrote the book Clean Code very interesting too.
1
I’ll give you a hint of how you might have thought of this organization, which seems to me thought of as a SOA application:
But to really know, just looking at the code.
1
If you yet is not able to understand a proposed layering pattern, just don’t use it. No use simply putting N layers if you don’t understand why each one exists.
There is a concept KISS (Keep it simple, stupid), I’m not calling anyone stupid, it’s the concept. Translating is keep it simple. Watch this lecture from a Stackoverlflow contributor, it’s in English. You’ll see the simplicity behind this site. Simplicity often meets.
In most cases the simple MVC standard that comes by default in an ASP.NET solution will meet. In your case of an API, you won’t get the Views, but you wouldn’t have to go out creating layers unless it’s extremely necessary, and if you can’t identify if it’s necessary, then don’t.
Focus on delivering the functionality to the customer in a safe and well-done way, at least following the basic principles of object orientation such as separation of responsibility and the DRY.
Take this layer pattern, and try to develop something for testing, so you can learn and understand, but don’t do something that will be sold or put into production with something you don’t master.
Browser other questions tagged c# api pattern-design
You are not signed in. Login or sign up in order to post.
The correct answer is that a project does not necessarily represent a layer. Based on this statement no one will know how to give an answer without knowing exactly the code of each project
– Bruno Costa
Hello! Can you tell what is the original intention of each project created?
– Dherik
@Dherik, where I was studying, got a little confused, because all the projects were doing the same thing. I was just calling another project to call another... so I thought it was unnecessary
– Diego Zanardo