In some cases it may be true, however, for bigger projects the services usually work with multiple Domain Objects and DAOs. Where will the service reside in this case? It is completely acceptable to further categorize services based on common working grounds, but I still believe the general structure should be similar to the one I presented.
I wasn't referring to domain objects but rather domain from Domain-Driven-Design:
Domain
A sphere of knowledge (ontology), influence, or activity. The subject area to which the user applies a program is the domain of the software;
Services will live within the domain they deal with. It might be just me, but when I browse code I don't think: am I looking for a service or a controller but rather what part of my app is responsible for this. For instance, if I see a problem within the shipping endpoint I'd expect the code that I need to fix to be within the shipping folder.
The DAOs and domain objects of one service should be contained within that service's domain. The representation of what a customer is will likely vary between domains, having a single representation can cause pain in the long run.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I find it way more intuitive to split your application by domain.
Within each domain folder you can then have controllers or services related to that domain.
In some cases it may be true, however, for bigger projects the services usually work with multiple Domain Objects and DAOs. Where will the service reside in this case? It is completely acceptable to further categorize services based on common working grounds, but I still believe the general structure should be similar to the one I presented.
I wasn't referring to domain objects but rather domain from Domain-Driven-Design:
Services will live within the domain they deal with. It might be just me, but when I browse code I don't think: am I looking for a service or a controller but rather what part of my app is responsible for this. For instance, if I see a problem within the shipping endpoint I'd expect the code that I need to fix to be within the shipping folder.
The DAOs and domain objects of one service should be contained within that service's domain. The representation of what a customer is will likely vary between domains, having a single representation can cause pain in the long run.