Reading the literature of DDD I came up with the following layers:Application Outsider World (Controllers, Crons, etc)Application Services (or UseCases) - which orchestrates multiple Domain Services or Infrastructure Services. They are called from Outside World. They know what things have to be doneDomain Services - which contains how the things are done (relying on repository interfaces)Question: Is there any best practices how to communicate between layers? What I know:- Application services should return wanted data to be exposed and some of success of the transaction (warnings, error, infos)- The data that an Application Service returns, should be gathered from Domain Services and/or Infrastructure Services and composed togather.Controller <-> Application Service <-> Domain Service                                             <-> Infrastructure ServiceThese are some of my ambiguous thoughts:Should all methods on Application Service have a specific DTO that contain the request as a parameter?  Like AddItemToCardCommandDto (that encapsulated all the needed data). How about a generic ResultObject that have only a couple of methods like getResult and hasErrorrs or getMessages?How should return DomainService data and errors? Should they Return errors by  exception? That seems odd because to me Bussines Validation should be called in DomainServices as they are part of business rules.
Comunicating between layers in DDD
domain driven design