La primera pregunta se resolverá haciendo énfasis en usar el concepto de ubiquitous language que intenta transmitir DDD. Si alineamos nuestros conceptos con el negocio, los objetos tendrán esos mismos nombres.
Para resolver la segunda gran pregunta usaremos las Territory card. Las Territory card definen las áreas donde va a suceder la acción. Sin ellas, los otros componentes no podrían moverse por la aplicación. La intención de las Territory card es poder saber dónde poner cada cosa.
En la baraja existen tres Territory card transversales. Abarcan conceptos que afectan a todo el gráfico o en gran parte. Con lo que se usarán de forma especial para referirnos a dichos conceptos organizativos. Realmente se articulan en nombres que usaremos en nuestra jerarquía de carpetas.
Las cartas transversales son:
- Bounded context
- Module
- Domain
También hay dos Territory card conceptuales. No existen como tal cuando vayamos a articular la estructura de carpetas, pero es importante saber que existen como concepto de Territory card en el juego.
Las cartas conceptuales son:
- Primary adapters
- Secondary adapters
Lo interesante es que aun siendo conceptuales, las dos primeras cartas de la lista las usaremos en el tablero para abrir la partida.
La diferencia entre un territorio de tipo Primary adapters y otro de tipo Secondary adapters es que los Primary adapters son requeridos por el User, como la petición que entra en el Domain y los Secondary adapters son de los que se sirve el Domain para poder cumplir el objetivo del User, como una consulta en base de datos o publicar un Domain event.
El resto de Territory card son:
- User interface (UI para los amigos)
- Application layer
- Domain layer
- Domain model
- Infrastructure layer
En estas capas sucede la acción, con lo que necesitamos dichas Territory card para que el resto de componentes puedan existir.
Las siguientes Territory cards deben ser puestas en el tablero según la plantilla del mismo.
- Primary adapters
- Secondary adapters
- Infrastructure layer
TODO (TABLERO)