Cuestionario DDD

Question 1

¿Qué es Domain Model?

Answer 1

Modelar explícitamente el Dominio

Question 2

¿Cuáles son las 4 capas de la Arquitectura en capas?

Answer 2

• User Interface / presentación
• Aplicación
• Dominio
• Infraestructura

Question 3

¿Cuáles son los servicios de DDD?

Answer 3

• Servicios de dominio : objetos que tienen lógica de negocio y como son parte de mi dominio no tienen ninguna conexión con la infraestructura. Donde se pone la lógica que excede a las clases de negocio. Ejemplo : si no quiero que se repita el mismo usuario, la clase usuario desconoce la existencia de otros usuarios por eso lo pongo en el servicio de dominio.
• Servicios de aplicación : tienen lógica de alto nivel que tienen que ver con la aplicación en particular. Son objetos que representan una transacción que hace el usuario que implica la coordinación de diferentes objetos del dominio. Representan una transacción del usuario, coordinando objetos del dominio.
• Servicios de Infraestructura : son librerías que va a utilizar la aplicación (ej : persistencia). Habla de funcionalidades que mi aplicación requiere como infraestructura

Question 4

¿Qué son repositorios en DDD?

Answer 4

El repositorio es un tipo de objeto que no tienen lógica de negocio, solo manejan el ciclo de vida de los objetos luego de que fueron creados.
La interfaz del repositorio es parte del dominio.
La implementación del repositorio es parte de la infraestructura no del dominio (tengo que poder cambiar la estructura sin cambiar el dominio).
No tienen lógica de negocio.

Question 5

¿Qué propone el patrón : Model - View - Controller?

Answer 5

Propone una separación de los objetos de nuestra aplicación con el fin de tener un poco más de flexibilidades.
Para aplicaciones interactivas (el usuario hace algo a partir de una vista, se genera una acción que es interpretada por el controller que la traduce en un mensaje al modelo, el modelo se modifica y la vista refleja el nuevo estado del modelo)

Question 6

¿Por qué no se pone lógica de negocio en los controllers?

Answer 6

Porque testear los controllers es muy difícil.
Quedaría muy atado a la estructura y necesitaría test end-to-end para testearlo que son mucho más costosos, difíciles de hacer y de mantener.