Malachite
Plataforma de código abierto para propuestas comerciales y planificación de servicios.
El sistema que habría construido si los dos que lancé se hubieran diseñado como uno desde el inicio. Propuestas que se revisan, valorizan y auditan, y luego se convierten en un plan con frentes de trabajo, recursos dimensionados y requerimientos: un solo dominio en lugar de dos que deben conciliarse. Escrito desde cero en mi tiempo libre, con Django en lugar del FastAPI que ya conocía, y de forma abierta para que el razonamiento pueda revisarse.
- Estado
- En desarrollo
- Periodo
- 2026 — presente
- Contexto
- Código abierto · Personal
- Dominios
- Comercial · Planificación · Cuentas · Compartido
El problema
El trabajo comercial y de planificación en servicios industriales vive en hojas de cálculo y cadenas de correos. Las revisiones se sobrescriben, el número cotizado a un cliente se vuelve imposible de reconstruir y el plan detrás de ese número nunca queda conectado con él. La parte difícil no es la interfaz: es modelar una propuesta que cambia con el tiempo sin perder la historia de lo acordado.
Enfoque
- 01Modelar la propuesta como una entidad con revisiones inmutables, para poder reconstruir exactamente cualquier versión anterior.
- 02Congelar los precios en snapshots económicos al momento de cada revisión, desacoplando las cifras reportadas de cambios posteriores en el catálogo.
- 03Derivar la planificación —frentes de trabajo, dimensionamiento de recursos y requerimientos— a partir de una revisión aprobada, manteniendo un vínculo trazable entre lo vendido y lo ejecutado.
- 04Registrar una auditoría en cada transición de estado, como parte de primera clase del dominio y no como un añadido posterior de logging.
Arquitectura
Cómo está construido.
Django + DRF, monolito modular
Un único despliegue con límites internos explícitos. Cada contexto es dueño de sus modelos y servicios; el acceso entre contextos pasa por una interfaz pública estrecha en lugar de entrar directamente a las tablas de otra aplicación.
Contextos delimitados
Comercial (propuestas, revisiones y snapshots), Planificación (frentes de trabajo, dimensionamiento y requerimientos), Cuentas (identidad y permisos) y Compartido (primitivas transversales).
Historial de solo adición
Las revisiones y los snapshots se escriben y nunca se mutan. La auditabilidad surge del modelo de datos en lugar de reconstruirse a partir de logs.
Persistencia portable
PostgreSQL como primera opción, manteniendo compatibilidad con SQL Server —la restricción que realmente imponen muchos despliegues empresariales.
Frontend en React
Un cliente React tipado contra la API de DRF, limitado a los flujos que necesitan interactividad real.
Docker + GitHub Actions
Un entorno local reproducible y CI ejecutando la suite de pruebas y los linters en cada push.
Stack
- Backend
- Python
- Django
- Django REST Framework
- Frontend
- React
- TypeScript
- Vite
- Datos
- PostgreSQL
- Compatible con SQL Server
- Plataforma
- Docker
- GitHub Actions
Resultado
- La referencia pública de cómo estructuro un backend con un dominio complejo: límites, nomenclatura, pruebas y migraciones.
- Escrito desde cero en mi tiempo libre sobre un problema genérico —no incluye código, datos ni información de clientes del empleador.
- Una forma deliberada de aprender Django y límites al estilo DDD, viniendo de FastAPI.
- En desarrollo —el repositorio se hará público cuando haya algo que valga la pena leer.