18 de marzo de 2026

·Decisiones de arquitectura

Definir el stack despues del problema, no antes

Evitar decisiones prematuras de tecnologia permitio disenar un sistema mas claro y sin acoplamientos innecesarios.

Durante la definicion del CRM surgio una tension comun: elegir herramientas antes de cerrar el problema.

Se freno esa decision para ordenar primero el sistema.

Decision de arquitectura

Primero se definio:

  • que debia resolver el sistema
  • que partes eran dominio
  • que partes eran integracion

Recien despues se evaluo el stack.

Hallazgo de implementacion

Evitar definir tecnologia por adelantado redujo acoplamientos innecesarios.

Resultado del trabajo diario

Menos dependencia de herramientas. Mas control sobre la arquitectura.

Idea central

Definir el problema primero permite elegir mejor el stack.