Notas
- Bounded Context
- DDD no depende de una arquitectura o patrón de arquitectura concreto, la elección de estas deben estar orientadas solo a satisface los requerimientos de calidad de software y estas no pueden ser determinadas sin los requisitos funcionales
- Delegar a otro Bounded Context la tarea de generar la identidad
- Delegar la generación de la identidad en el sistema de persistencia
- Domino central
- El uso de una interfaz de uso de proposito general permite evitar implementar más interfaces de las necesarias en una clase
- Entidad (DDD)
- Espacio de solución (DDD)
- Espacio del problema (DDD)
- Estrategias para crear identificadores de las entidades
- Generar la identidad en la aplicación
- Impacto del momento en el que se produce una identidad (DDD)
- La arquitectura hexagonal es una base sólida para respaldar todas y cada una de los posibles patrones arquitectónicos disponibles
- La arquitectura hexagonal permite desarrollar todo el modelo de aplicación y dominio usando implementaciones fake de las interfaces de dominio
- La trampa de crear un modelo inclusivo, que intenta abarcar todo
- Lo deseable es una relación 1-1 entre subdominos y bounded context
- Los roles de una clase se determinan por medio de las interfaces que implementan
- Los setters públicos en sí no son un problema, la cuestión es si su uso genera ambigüedad o si es necesario el uso de multiples de estos para resolver una única petición
- Permitir a los usuarios proveer la identidad
- Pistas para identificar una entidad un modelado en DDD
- RESTful HTTP y DDD
- Subdominio genérico
- Subdomino de soporte
- Surrogamiento del identidad
- Un Bounded Context debe ser tan grande como sea neceario para expresar completamente su lenguaje ubicuo
- Un Bounded Context solo debe ser trabajado por un equipo
- [[Notas/Una manera de nombrar un Bounded Context es siguiendo la forma de
NombreDelModeloCentral Context]]