Qué queda afuera

Con el tiempo, muchas arquitecturas terminan acumulando piezas que nadie se atreve a quitar. No porque sigan resolviendo un problema, sino porque alguna vez fueron consideradas una buena práctica. DFE prefiere preguntar primero qué necesidad concreta resuelve cada pieza.

Estas piezas no forman parte de la convención mientras no resuelvan un problema que ya existe:

• Una capa intermedia que no agrega una regla, un límite o una semántica.
• Un trait Repository por tabla.
• Puertos y adaptadores para una base de datos que no se va a cambiar.
• Un usecase que solo reenvía la llamada.
• DTOs y From/Into en cada frontera, cuando el comando ya es el dato.
• Un JOIN usado como lugar donde vive una regla de negocio.
• Eventos para que el mismo servicio se entere de lo que acaba de escribir.
• Mocks de la base de datos para probar un flow. La regla pura se prueba en el dominio. El flow se prueba contra la base real.

Un trait sigue siendo la herramienta correcta cuando hay dos implementaciones reales, por ejemplo dos pasarelas de pago.

DFE usa las propiedades de Rust para organizar el sistema: datos explícitos, funciones con un solo trabajo y el compilador como lista de lo que falta. Los nombres de las carpetas evitan los de otras arquitecturas para no arrastrar sus hábitos antes de tiempo. No se trata de rechazar una herramienta por su nombre, sino de no introducirla antes de que exista una razón.