Comunicarse entre capas en DDD

8

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. Se llaman desde Outside World . Saben qué cosas deben hacerse
  • Domain Services - que contiene cómo se hacen las cosas (basándose en las interfaces del repositorio)

Pregunta : ¿Existen prácticas recomendadas sobre cómo comunicarse entre capas?

Lo que sé: - Application services debería devolver los "datos deseados" para ser expuestos y algunos de los "éxitos" de la transacción (advertencias, errores, informaciones) - Los datos que devuelve Application Service , deben recopilarse de Domain Services y / o Infrastructure Services y deben estar compuestas.

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

Estos son algunos de mis pensamientos ambiguos:

  • ¿Todos los métodos en Application Service tienen un DTO específico que contenga la "solicitud" como parámetro? Como AddItemToCardCommandDto (que encapsuló todos los datos necesarios). ¿Qué tal un ResultObject genérico que tiene solo un par de métodos como getResult y hasErrorrs o getMessages ?

  • ¿Cómo se deben devolver los datos y errores de DomainService ? ¿Deben devolver los errores por excepción? Eso parece extraño porque para mí, la validación de negocios debería llamarse en DomainServices , ya que son parte de las reglas comerciales.

pregunta user237329 31.05.2016 - 10:15

1 respuesta

1

Yo diría que tener DTO diluiría el diseño del modelo. Podemos evitar tener que no usar DTOs 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 queremos 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 las diferentes capas se comuniquen entre sí a través de esa interfaz para todos los componentes de la aplicación.

Por ejemplo:

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 lo recuerdo bien. 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. Las excepciones se pueden utilizar para conectar información en cascada a través de capas. Los datos pueden estar contenidos dentro de marcadores de posición de excepciones personalizadas para negocios.

Espero que esto responda algunas de las preguntas que tienes.

    
respondido por el pavan kumar chaitanya 29.08.2017 - 21:19

Lea otras preguntas en las etiquetas