Comunicação entre camadas no DDD

Lendo a literatura do DDD, criei as seguintes camadas:

• Application Outsider World (Controladores, Crons, etc)
• Application Services(ou UseCases) - que orquestra vários serviços de domínio ou serviços de infraestrutura. Eles são chamados de Outside World. Eles sabem o que as coisas precisam ser feitas
• Domain Services - que contém como as coisas são feitas (contando com as interfaces do repositório)

Pergunta : Existem práticas recomendadas de comunicação entre camadas?

O que eu sei: - Application servicesdeve retornar "dados desejados" a serem expostos e alguns dos "sucessos" da transação (avisos, erros, informações) - Os dados Application Serviceretornados por uma empresa devem ser coletados Domain Servicese / ou Infrastructure Servicescompilados.

Controller <-> Application Service <-> Domain Service          
                                   <-> Infrastructure Service

Estes são alguns dos meus pensamentos ambíguos:

• Todos os métodos Application Servicedevem ter um DTO específico que contenha a "solicitação" como parâmetro? Like AddItemToCardCommandDto(que encapsulou todos os dados necessários). Que tal um genérico ResultObjectque tenha apenas alguns métodos como getResulte hasErrorrsou getMessages?

• Como deve retornar DomainServicedados e erros? Eles devem retornar erros por exceção? Isso parece estranho, porque para mim a Validação DomainServicesde Negócios deve ser chamada , pois faz parte das regras de negócios.

Eu diria que ter DTOs diluiria o design do modelo. Podemos evitar o uso de DTOs refatorando nosso Modelo e projetando nossas APIs para usar os objetos de modelos refatorados.

A resposta para a consulta 1: o serviço de aplicativo pode ter métodos com uma assinatura

void addItemToCard(Item item, Card card);

Os métodos podem ter um tipo de retorno ou não, com base no tipo de operação que estamos procurando executar e nos dados que queremos transferir através das camadas. Você precisa garantir que cada camada tenha uma interface especificada e que diferentes camadas se comuniquem através dessa interface para todos os componentes no aplicativo.

Por exemplo:

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

Garantir que todos os métodos estejam em conformidade com o mesmo comportamento é mais importante para manter a interface intacta.

Resposta à consulta 2:

Eu acho que o DDD recomenda ter 3 camadas se bem me lembro. Ter inteligência de domínio na camada de aplicativo ajuda e significa que seu aplicativo está vinculado ao domínio e tem um contexto limitado. Você pode adicionar camadas adicionais se achar que 3 não é suficiente. Exceções podem ser usadas para cascatear informações entre camadas. Os dados podem estar contidos em espaços reservados de exceções personalizadas para negócios.

Espero que isso responda a algumas das perguntas que você tem.