Bienvenidos a una nueva serie. En los próximos posts veremos paso a paso cómo he ido cocinando a fuego lento una aplicación CLI para gestionar tareas (To-Do’s). Esta idea nació con el propósito de resolver uno de los retos propuestos por CodeCrafters: Project #1 - CLI To-Do List App.
Este primer artículo sirve como punto de entrada y recetario. El objetivo es que puedas leer cada capítulo con el repositorio abierto en la otra pantalla y, en lugar de quedarte solo en la teoría, puedas seguir cada decisión arquitectónica y cada ingrediente que añadimos directamente en el código real.
Repositorio base del proyecto: github.com/rafafrdz/todo-cli-rs
Cómo leer esta serie (sin perderte) #
Orden recomendado:
- Arquitectura y límites,
- Dominio y errores,
- Persistencia: contrato vs implementación, 3.1. Estrategia de pruebas y deuda técnica,
- CLI y contrato de salida,
- Evolución a TUI con ratatui.
Ese orden no es casual. Refleja de manera natural cómo se construyó el proyecto: primero decisiones de diseño, luego implementación por capas.
Capítulos de la serie (el menú degustación) #
1) Los cimientos de la cocina (Arquitectura) #
- Post:
Todo CLI en Rust 1. Arquitectura hexagonal en un proyecto pequeño - Enlace recomendado: docs/architecture.md
- Complemento: docs/step-1-mvp.md
Aquí se explica por qué se eligió hexagonal + screaming architecture en un proyecto pequeño, y qué problemas evita cuando empiezas a iterar.
2) Los ingredientes principales (Dominio y errores) #
- Post:
Todo CLI en Rust 2. Dominio inmutable y errores tipados por capa - Enlaces:
Este bloque es el corazón del sistema: invariantes, transiciones de estado y propagación de errores con contexto.
3) La despensa (Persistencia: contrato vs implementación) #
- Post:
Todo CLI en Rust 3. Persistencia JSON, contrato vs implementación - Enlaces:
Este capítulo define el contrato de repositorio con un trait, implementa dos adapters (in-memory y JSON a disco) y profundiza en la inversión de dependencias materializada en Rust.
3.1) Las catas (Estrategia de pruebas y deuda técnica) #
- Post:
Todo CLI en Rust 3.1. Estrategia de pruebas y deuda técnica explícita - Enlaces:
- src/tasks/adapters/persistence/in_memory_task_repository.rs (módulo
tests) - src/tasks/adapters/persistence/json_file_task_repository.rs (módulo
tests)
- src/tasks/adapters/persistence/in_memory_task_repository.rs (módulo
Control de calidad de la despensa: tests por comportamiento para cada adapter, aislamiento con tempdir, por qué no compartimos tests entre implementaciones, y la deuda técnica que documentamos en vez de esconder.
4) Emplatado básico (Capa CLI) #
- Post:
Todo CLI en Rust 4. Creando el CLI con clap - Enlaces:
Aquí se conecta UX de terminal con contrato técnico: parseo fuerte, Uuid tipado y salida dual table/json.
5) Estrella Michelin: de CLI a TUI (ratatui) #
- Post:
Todo CLI en Rust 5. Siguiente paso, pasar de CLI a TUI con ratatui - Enlaces:
Este cierre propone la evolución natural del proyecto: añadir un nuevo adaptador de interfaz (TUI) reutilizando dominio y casos de uso actuales.
Qué te llevas si pruebas el menú completo #
Al terminar de devorar los 6 artículos habrás visto:
- Cómo diseñar una CLI en Rust sin convertir
main.rsen un amasijo de espaguetis acoplados. - Cómo usar Arquitectura Hexagonal para aislar dominio, aplicación e infraestructura de forma pragmática.
- Cómo modelar errores fuertemente tipados que ayuden tanto al comensal (usuario final) como al cocinero (desarrollador).
- Cómo preparar el proyecto para evolucionar la receta (añadir interfaces gráficas o cambiar bases de datos) sin que se corte la salsa.
Si te interesa construir herramientas de terminal en Rust que aguanten cambios reales y se sientan robustas, esta serie te va a aportar bastante más que un tutorial de “todo app en 15 minutos al microondas”. ¡Nos vemos en los fogones del primer capítulo!