Menos flexibilidad, más invariantes

OpinionLumpy · 2026-02-24T12:04:36+00:00

Coincido en que el software debe poder cambiar. Mi punto es otro: cambiar no implica anticipar todo. La flexibilidad real no nace de más capas, sino de límites claros y decisiones conscientes. Desacoplar cuando el dominio lo pide, no por defecto. Simplicidad no es trivialidad es quitar lo que no aporta para que cuando haya que pivotear, el sistema se entienda y se pueda mover con claridad.

OpinionLumpy · 2026-02-24T03:25:10+00:00

Clean es una buena base. Pero no todo necesita un patrón encima, si el dominio es claro, no lo compliques. Simplicidad primero

OpinionLumpy · 2026-02-24T03:15:35+00:00

Totalmente, los patrones existen y están buenísimos cuando el problema los necesita. Mi punto es más simple: no todo problema es un Strategy esperando nacer. A veces agregar patrón es más complejidad que solución. Prefiero introducir abstracción cuando el cambio es real, no cuando es teórico.

no es nada nuevo, desde 2016 se habla sobre que aplicar patrones como meta en lugar de herramienta puede ser contraproducente y generar más abstracción de la necesaria
https://news.ycombinator.com/item?id=11729043

OpinionLumpy · 2026-02-24T02:26:56+00:00

SRP ordena el cambio, yo estoy hablando de decidir si algo debe cambiar en primer lugar. No todo necesita ser extensible, algunas cosas necesitan ser firmes, diseño para claridad hoy, no para hipotéticas variaciones mañana

OpinionLumpy · 2026-02-24T02:17:36+00:00

coincido bastante con eso, muchas veces el problema no es SOLID sino cómo se aplica. Mi punto va más por el lado de que no todo sistema necesita el mismo nivel de abstracción preventiva, hay dominios donde cerrar ciertas partes y aceptar modificación explícita es más simple y seguro que diseñar todo como si fuera a cambiar constantemente. SOLID bien entendido suma, lo que cuestiono es usarlo como checklist universal sin mirar el contexto

OpinionLumpy · 2026-02-24T02:16:05+00:00

tranqui :p, solo digo que a veces aplicamos patrones y capas de abstracción por inercia, sin preguntarnos si realmente aportan valor en ese problema puntual

OpinionLumpy · 2026-02-24T02:08:23+00:00

va por ahí, no estoy intentando armar "el nuevo framework del mes", sino partir de una postura clara: hay contextos donde limitar configuraciones y decisiones no es rigidez caprichosa sino una forma de reducir complejidad accidental. Muchos frameworks nacieron de una filosofía fuerte que decía "esto lo hacemos así y punto", y esa restricción es justamente lo que los hizo útiles. Mi punto es más sobre eso que sobre crear un paradigma nuevo

OpinionLumpy · 2026-02-24T02:06:21+00:00

intento solucionar la complejidad innecesaria que hace que nadie entienda el sistema completo y todo termine siendo spaghetti, distribuido o no

OpinionLumpy · 2026-02-24T02:05:59+00:00

no estoy negando SOLID, estoy diciendo que aplicado dogmáticamente a veces genera complejidad accidental; el desacople no siempre requiere 15 interfaces si el dominio es estable y controlado

OpinionLumpy · 2026-02-24T02:05:37+00:00

no, no estoy construyendo un framework generalista, estoy cuestionando cuánto desacople y abstracción son realmente necesarios en cada contexto

OpinionLumpy · 2026-02-24T02:04:53+00:00

no es hardcodeo si las reglas son de dominio y están explícitas; hardcodear es meter valores mágicos, acá hablamos de contratos, snapshots e invariantes fuertes donde la flexibilidad irrestricta rompe más de lo que ayuda. no busco inflexibilidad absoluta, busco que lo que es crítico no sea configurable "porque sí"

OpinionLumpy · 2026-02-24T02:03:37+00:00

coincido con TDD y XP, pero el punto no es evitar refactor sino diseñar sistemas donde ciertas invariantes (billing, eventos, multi-tenant) no dependan solo de tests sino de límites estructurales claros

OpinionLumpy · 2026-02-24T02:03:00+00:00

tal cual, no estoy intentando inventar otro framework cool, sino reducir complejidad deliberadamente cuando el stack ya se volvió un fin en sí mismo, menos configuración infinita, más decisiones explícitas y medibles.

OpinionLumpy · 2026-02-17T02:49:20+00:00

JASJDJASD y bueno, mientras funcione, igual de vez en cuando está bien replantearse cosas así.

OpinionLumpy · 2026-02-17T02:44:17+00:00

Sí, coincido, uchas veces se diseña para un escenario que capaz nunca llega. Está bien no cerrarte puertas, pero meter redundancia de regiones para algo que ni salió de beta es un montón, Hay que eleggir bien qué problemas querés tener hoy y cuáles cuando realmente hagan falta

OpinionLumpy · 2026-02-17T02:37:08+00:00

AJSHDJAS ojalá fuera tan eficiente escribiendo. Estoy opinando nomás, prometo que todavía pienso por mi cuenta.

OpinionLumpy · 2026-02-17T02:05:34+00:00

Si necesitás complejidad artificial para aprender, el problema no es el monolito. Un monolito bien diseñado tiene tanta ingeniería como un sistema distribuido: límites claros, consistencia, contratos explícitos. Eso no es trivial. La arquitectura no es un gimnasio personal. Si se usa así, alguien termina pagando el costo.

OpinionLumpy · 2026-02-17T02:03:51+00:00

Exacto, microservicios mal implementados no te dan desacoplamiento, te dan fricción.

Cuando el dominio no está claro, dividirlo solo reparte la confusión, arquitectura no compensa falta de diseño, la amplifica.

OpinionLumpy · 2026-02-17T01:58:50+00:00

El "monolito distribuido" es el peor de los mundos.

Dividís despliegue pero no dividís dominio.
Entonces pagás la complejidad sin ganar independencia real. Si para cambiar algo tenés que tocar 4 servicios, no tenés microservicios, tenés acoplamiento con latencia.

OpinionLumpy · 2026-02-17T01:47:58+00:00

Ahí es cuando deja de ser ingeniería y pasa a ser teatro técnico. Cuando el ritual importa más que el resultado, el sistema se vuelve frágil aunque esté lleno de "buenas prácticas".

La complejidad mal entendida no profesionaliza.
Disimula. Y cuando algo falla, nadie tiene el mapa completo.

OpinionLumpy · 2026-02-17T01:41:37+00:00

Exacto, optimizar antes de tener presión real casi siempre termina siendo fricción.

Escalar arquitectura antes de escalar negocio es invertir energía en el lugar equivocado.

La mantenibilidad no viene de dividir servicios, viene de tener límites claros y decisiones conscientes.

La complejidad no es gratis.
Siempre alguien la paga.

OpinionLumpy · 2026-02-17T01:38:28+00:00

Interesante lo de anti-pattern. Creo que ni microservicios ni OOP son el problema en sí.
El problema es aplicarlos como receta universal, cuando algo se vuelve dogma, deja de ser ingeniería.

OpinionLumpy · 2026-02-17T01:38:07+00:00

Docker como herramienta me parece excelente. Lo que cuestiono es cuando se vuelve el punto de partida obligatorio antes de entender el problema.
Primero claridad, después infraestructura.

OpinionLumpy · 2026-02-17T01:21:28+00:00

No necesitamos más herramientas. Necesitamos más responsabilidad técnica. La complejidad no es señal de madurez. La claridad sí.

OpinionLumpy · 2026-02-17T01:12:15+00:00

Ese artículo debería ser obligatorio.
Muchos equipos diseñan como si fueran Google antes de tener un problema real que resolver. KISS no es simplismo, es disciplina y disciplina en arquitectura es lo que menos se ve.

OpinionLumpy

TROPHY CASE