====== 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)**.

===== 1. Qué se pide =====

  * 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.

===== 2. Con qué =====

  * 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).

===== 3. Decisiones tuyas =====

  * ¿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''.

===== 4. Comprobación =====

  * 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.

===== 5. Pendientes =====

  * 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**).