08 - La Forja: en capas

El programa principal mezcla menú, reglas de negocio y estado interno, y pensar en “cambiar la consola por una API” implica rehacerlo todo. El paso aplica el tema: arquitectura por capas, DTO con Java records, mapeadores e inyección de dependencias (IoC manual).

• El proyecto se reparte en las tres capas — presentación, negocio y persistencia —, cada una en su paquete, sobre el modelo compartido:
  • la consola solo presenta: menú, lectura y escritura; nada de reglas ni de acceso directo a los datos.
  • el negocio concentra las reglas: registrar, equipar, informes, cálculo de poder;
  • la persistencia guarda y consulta héroes e ítems (aún en memoria).
• Las reglas de comunicación del tema se cumplen: flujo en una dirección, no se salta capas y de abajo no se llama a arriba.
• Los datos que cruzan la frontera del negocio viajan en DTO records: entrada sin lo que la app asigna sola, salida con lo ya calculado. El modelo del gremio y lo que ve la consola no son el mismo idioma.
• La traducción entre ambos mundos tiene su lugar: mapeadores, no puntos sueltos.
• Cada capa recibe sus dependencias por constructor, y el ensamblado ocurre en un único punto: el main.
• Todas las pruebas anteriores pasan enteras.

• Todo lo del tema: capas y sus reglas, DTO con records, mapeadores, e inyección de dependencias manual (programar contra interfaces, recibir por constructor, un único punto de ensamblado).

• ¿Cómo se llaman las capas en paquetes y clases? Usa nombres que digan responsabilidad: qué hace cada una, no “servicio del servicio”.
• ¿Qué interfaces fijan las capas (negocio y persistencia) y qué promete cada una? El estilo del tema: programa contra lo abstracto, ensambla lo concreto.
• ¿Qué son “los datos mínimos” de un héroe para crearlo? ¿Y los de la ficha? Son los campos de tus DTO: ¿qué viaja en la salida que quien consulta no sabría calcular por sí solo, y qué queda solo en el dominio?
• ¿Qué hace el mapeador con lo que la consola no necesita (identificadores internos, datos derivados)?
• ¿Quién es responsable del estado de la plantilla y de la forja? Deja de ser variables estáticas: la capa de persistencia mantiene los datos — decisión: memoria por dentro, interfaz de repositorio por fuera.
• ¿Dónde ensamblas las dependencias? El punto único es ahora el main.

• La consola no toca colecciones ni reglas: solo llama al negocio, que es la única puerta.
• De abajo no sale arriba: ninguna clase de negocio o persist imprime nada.
• Cambiar el almacenamiento en memoria por otro (fichero, colección distinta) no toca la capa de negocio: solo la implementación del repositorio.
• Las fichas impresas vienen de DTO: el formato del “¡Aquí está tu ficha!” es cosa de la consola; el cálculo ya lo hizo el negocio.
• El ensamblado está en un punto único y todas las dependencias se inyectan por constructor: ninguna capa se instancia sus propias dependencias.
• Las pruebas de los pasos anteriores pasan enteras.

• La presentación sigue siendo consola: un único usuario en el mismo ordenador → contrato REST diseñado a mano (09) y su implementación (10).
• El repositorio en memoria guarda todo en vivo y luego será compartido… ¿por quién? → hilos (11).