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 done
  • Domain 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 Service

These 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.

  • 1
    DDD is not a programming technique. Perhaps you're referring to Multi-Layered Architecture? – Robert Harvey May 31 '16 at 19:22
  • DDD it is more "approach to software development". From what I understood I came up with some layers. Can you detail more about your comment? – user237329 May 31 '16 at 19:52
  • Multi-Layered Architecture comes with its own set of "best practices." Have you studied those practices yet? DDD doesn't have anything to say about how your software layers communicate, other than to possibly establish which layers you're going to use. – Robert Harvey May 31 '16 at 21:52
  • OK, can you share some of these best practices that apply to my question? I have not studied in particular this subject – user237329 May 31 '16 at 22:03
  • 3
    Maybe you should.... What is your question, exactly? Can you state it in such a way that isn't a big list of things or requires a book chapter to answer? – Robert Harvey May 31 '16 at 22:04

I would say having DTOs would dilute the design of the Model. We can get away with having to not use DTOs by refactoring our Model and designing our APIs to use the refactored models objects.

The answer to query 1: The application-service can have methods with a signature

void addItemToCard(Item item, Card card);

The methods can have a return type or not, based on the kind of operation we are looking to perform and the data we want to transfer across layers. You need to make sure that each layer has a specified interface and different layers speak to each other through that interface for all components in the application.


List<Items> getItemsOnCard(String cardID);
//returns list of items or empty list if no item can be found.

List<Offers> getOffersApplicableOnCardForItem()
//should return list of Offers or empty list if no item can be found. Should not return a null if no items can be found

Making sure that all methods comply with the same behavior is more important in keeping the interface intact.

Answer to query 2:

I think DDD recommends having 3 layers if I remember it right. Having domain intelligence in the application layer helps and signifies that your application is bound to the domain and has a bounded context. You might add additional layers if you feel that 3 is not sufficient. Exceptions can be used to cascade information across layers. Data can be contained inside placeholders of custom exceptions for business.

I hope this answers some of the questions you have.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.