Comunicación entre capas en DDD

Leyendo la literatura de DDD se me ocurrieron las siguientes capas:

• Application Outsider World (Controladores, Crons, etc.)
• Application Services(o UseCases), que organiza múltiples servicios de dominio o servicios de infraestructura. Son llamados de Outside World. Ellos saben que cosas hay que hacer
• Domain Services - que contiene cómo se hacen las cosas (confiando en las interfaces del repositorio)

Pregunta : ¿Existe alguna práctica recomendada para comunicarse entre capas?

Lo que sé: Application servicesdebería devolver los "datos deseados" para exponerlos y parte del "éxito" de la transacción (advertencias, errores, informaciones). Los datos que Application Servicedevuelve deben recopilarse Domain Servicesy / o Infrastructure Servicescompilarse juntos.

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

Estos son algunos de mis pensamientos ambiguos:

• ¿Todos los métodos Application Servicedeben tener un DTO específico que contenga la "solicitud" como parámetro? Me gusta AddItemToCardCommandDto(que encapsula todos los datos necesarios). ¿Qué tal un genérico ResultObjectque solo tiene un par de métodos como getResulty hasErrorrso getMessages?

• ¿Cómo se deben devolver los DomainServicedatos y los errores? ¿Deberían devolver errores por excepción? Eso parece extraño porque para mí la validación DomainServicesde negocios debería llamarse ya que son parte de las reglas comerciales.

Yo diría que tener DTO diluiría el diseño del Modelo. Podemos evitar tener que no usar DTO refactorizando nuestro Modelo y diseñando nuestras API para usar los objetos de modelos refactorizados.

La respuesta a la consulta 1: el servicio de aplicación puede tener métodos con una firma

void addItemToCard(Item item, Card card);

Los métodos pueden tener un tipo de retorno o no, según el tipo de operación que estamos buscando realizar y los datos que queremos transferir a través de las capas. Debe asegurarse de que cada capa tenga una interfaz específica y que diferentes capas se comuniquen entre sí a través de esa interfaz para todos los componentes de la aplicación.

P.ej:

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

Asegurarse de que todos los métodos cumplan con el mismo comportamiento es más importante para mantener la interfaz intacta.

Respuesta a la consulta 2:

Creo que DDD recomienda tener 3 capas si no recuerdo mal. Tener inteligencia de dominio en la capa de aplicación ayuda y significa que su aplicación está vinculada al dominio y tiene un contexto acotado. Puede agregar capas adicionales si considera que 3 no es suficiente. Se pueden usar excepciones para transmitir información en cascada a través de capas. Los datos pueden estar contenidos dentro de marcadores de posición de excepciones personalizadas para empresas.

Espero que esto responda algunas de las preguntas que tiene.