Biblioteca de API-DD
API-DD Design
Guías prácticas sobre conversaciones, garantías y límites entre módulos. Si es tu primera visita, empieza por el manifiesto API-Driven Development.
El mock que hace fallar una refactorización correcta
Un mock exige Find seguido de Save para cancelar una reserva. Una implementación transaccional conserva el comportamiento, pero el test falla porque protegía el recorrido interno.
La dirección que no necesita llamarse NullAddress
Una dirección puede estar provista o no. NullAddress y AbstractAddress introducen categorías técnicas que no pertenecen a la conversación del consumidor.
El singleton que no puedes sustituir en un test
Un singleton parece simplificar el acceso a una dependencia, pero impide inyectar un doble local y obliga a los tests a usar el servicio real o modificar estado global.
El singleton que convierte una dependencia en estado global
Un recorder global parece cómodo hasta que dos tests necesitan configuraciones distintas: el singleton oculta la API requerida y comparte estado entre consumidores.
El nombre que obliga a abrir la implementación
Comparar OrderService.Process con Checkout.Place muestra cómo los nombres técnicos esconden la conversación y cómo encontrar vocabulario más estable.
El objeto que rompe su encapsulamiento para poder nacer
Decodificar JSON directamente en User obliga a exportar campos y permite estados inválidos; separar el DTO conserva la invariante y el encapsulamiento.