14.5 Bibliografía y estándar de salida Eje Z

Al terminar esta lección

• Elegir la lectura de referencia adecuada para una duda concreta de requerimientos, dominio, arquitectura, pruebas o modelado.
• Relacionar cada obra con el módulo del curso que la respalda, para volver a ella cuando el tema aparezca en un proyecto real.
• Armar una ruta de continuación de tres a cinco pasos según tu siguiente proyecto.
• Verificar, con el estándar de salida, si tu criterio profesional alcanza para trabajar sin un senior al lado.
• Explicar qué evidencia usarías para demostrar una decisión a alguien que no participó de ella.

Apéndice E · Bibliografía y lecturas de referencia

Las fuentes se utilizan como respaldo conceptual. El cuerpo del manual evita citas inline para mantener la lectura operativa y no reproduce la estructura de un temario académico.

La lista está agrupada por la pregunta que responde cada obra. No hace falta leerla completa: cuando una decisión te genere una duda, buscá el área y leé el capítulo que corresponde. Las anotaciones describen el tema de cada libro; no son citas ni resúmenes de su contenido.

Requerimientos, casos de uso y especificación

• Cockburn, Alistair. Writing Effective Use Cases. Addison-Wesley, 2000. Trata la escritura de casos de uso centrados en el objetivo del actor, con alcance, garantías y alternativos. Es la base del formato de CU-01 y de la discusión sobre garantía mínima y garantía de éxito (módulo 5).
• Wiegers, Karl; Beatty, Joy. Software Requirements. 3.ª ed. Microsoft Press, 2013. Cubre requerimientos de negocio, funcionales y no funcionales, y cómo escribirlos para que se puedan verificar (módulo 4).
• Adzic, Gojko. Specification by Example. Manning, 2011. Presenta ejemplos concretos como especificación compartida y su conversión en pruebas automatizables. Es la lectura para entender por qué el escenario Gherkin de la sobreventa es una especificación y no solo un test (módulos 6 y 10).

Dominio y arquitectura

• Evans, Eric. Domain-Driven Design. Addison-Wesley, 2003. Introduce el lenguaje ubicuo, los agregados y los límites de contexto. Es la lectura para el glosario, para la distinción entre "pedido confirmado" y "pedido listo para preparar", y para la frontera del sistema (módulos 2, 6 y 7).
• Fowler, Martin. Patterns of Enterprise Application Architecture. Addison-Wesley, 2002. Catálogo de patrones para aplicaciones empresariales, con unidad de trabajo, capas y acceso a datos. Sirve para justificar decisiones de transacción dentro del monolito modular (módulos 7 y 9).
• Nygard, Michael T. "Documenting Architecture Decisions". Blog de Cognitect, 2011. Artículo corto que propone registrar cada decisión arquitectónica con su contexto, decisión y consecuencias. Es el origen del formato de ADR usado en la lección 14.2 (módulo 7).
• Newman, Sam. Building Microservices. O'Reilly, 2015 (2.ª ed. 2021). Describe qué se gana y qué se paga al separar servicios. Es la contraparte necesaria para defender el monolito modular de ADR-001 sin caricaturizar los microservicios (módulo 7).
• Newman, Sam. Monolith to Microservices. O'Reilly, 2019. Se ocupa de cómo y cuándo migrar desde un monolito. Es la lectura para entender qué condiciones hacen que el disparador de revisión de ADR-001 se cumpla de verdad (módulos 7 y 8).
• Kleppmann, Martin. Designing Data-Intensive Applications. O'Reilly, 2017. Trata transacciones, concurrencia, consistencia e idempotencia en sistemas con datos. Es la referencia para la discusión de la última unidad y para entender qué garantiza una actualización condicional (módulos 7, 9 y 10).
• Martin, Robert C. Clean Architecture. Pearson, 2017. Plantea que las dependencias apunten hacia el dominio. Es un buen contraste con la arquitectura de Nexo: se puede discutir qué parte de esa propuesta aplica a un equipo pequeño (módulo 7).

Pruebas, entrega y cambio

• Beck, Kent. Test-Driven Development: By Example. Addison-Wesley, 2002. Muestra cómo escribir la prueba antes que el código para fijar un comportamiento. Es la base de la práctica de E09: el test que define la semántica de idempotencia antes del cambio (módulos 9 y 10).
• Humble, Jez; Farley, David. Continuous Delivery. Addison-Wesley, 2010. Trata despliegues repetibles, evidencia de cada cambio y reversibilidad. Es la lectura para el runbook, la migración expand/contract y el plan de rollback (módulos 8 y 11).
• Meszaros, Gerard. xUnit Test Patterns. Addison-Wesley, 2007. Catálogo de problemas de pruebas (fixtures frágiles, dobles que ocultan el comportamiento real) y de soluciones. Sirve para revisar la calidad de los tests de integración del módulo 10.
• Fowler, Martin. Refactoring: Improving the Design of Existing Code. 2.ª ed. Addison-Wesley, 2018. Explica cómo cambiar la estructura de un programa sin cambiar su comportamiento, apoyándose en pruebas. Es la lectura para los cambios con agente que tocan más de lo pedido (módulo 9).

UML y modelado

• Fowler, Martin. UML Distilled. 3.ª ed. Addison-Wesley, 2003. Una introducción breve que enseña a leer y dibujar los diagramas que realmente se usan, sin intentar cubrir toda la notación. Es la lectura para la lección 14.3.
• Larman, Craig. Applying UML and Patterns. 3.ª ed. Prentice Hall, 2004. Recorre análisis y diseño orientado a objetos con casos de uso, modelos de dominio y diagramas de secuencia (módulos 5 y 6).
• Booch, Grady; Rumbaugh, James; Jacobson, Ivar. The Unified Modeling Language User Guide. 2.ª ed. Addison-Wesley, 2005. Es la referencia completa de UML. No se lee de corrido: se consulta cuando la semántica de un diagrama, por ejemplo la dirección de un «extend», genera una duda.

Ingeniería de software en general

• Sommerville, Ian. Software Engineering. 10.ª ed. Pearson, 2015. Panorama general del proceso de software y de los requerimientos. Sirve como mapa cuando una discusión de proceso no encaja en un área específica.
• Pressman, Roger S.; Maxim, Bruce R. Software Engineering: A Practitioner's Approach. 9.ª ed. McGraw-Hill, 2019. Referencia práctica de proceso, calidad y gestión de proyectos. Útil para preparar la conversación con un responsable de proyecto que pida métricas.

Ruta de continuación

El curso termina, pero el criterio se construye en proyectos reales. Esta ruta sirve para los próximos tres o cuatro pasos, según el tipo de trabajo que te toque.

Tres reglas para la ruta. Primero, un caso real vale más que cualquier lectura: si no tenés un proyecto, buscá uno pequeño con alguien que tenga un problema de negocio concreto. Segundo, cada lectura se aplica en un artefacto que se pueda mostrar. Tercero, la revisión de alguien con más experiencia es parte del proceso, no un favor.

Cierre · El estándar de salida de Eje Z

El objetivo no es que termines pudiendo nombrar más diagramas. Es que, cuando aparezca un negocio que no conocés, sepas observar antes de afirmar, preguntar antes de inventar, convertir evidencia en una especificación discutible, detenerte cuando una incertidumbre es peligrosa, diseñar solo la complejidad que el riesgo exige, usar agentes sin delegar autoridad y demostrar con pruebas lo que prometiste.

Para contrastar la pregunta final con el trabajo concreto, el estándar se puede leer como dos columnas: lo que alcanza y lo que no alcanza.

Antes de cerrar el curso, comprobá tu respuesta a la pregunta final. Cada pregunta tiene una sola respuesta correcta.

Para cerrar, repasá el vocabulario del estándar de salida.

Para llevarte

• Usá la bibliografía por pregunta: cuando una decisión genere una duda, buscá el área y leé el capítulo que corresponde.
• Armá tu ruta de continuación con un caso real. Una lectura sin artefacto no se consolida.
• El estándar de salida se demuestra con evidencia: fuentes, decisiones con autoridad, huecos declarados y pruebas que verifican ausencias.
• Un senior no es el único que puede decidir; es quien revisa que tu decisión tenga fuente, consecuencia y límite escritos.