El combo BLoC y Clean Architecture cruje cuando el codigo Flutter escala
Un arquitecto con siete anos en Flutter repasa donde se rompe el patron que usa casi todo el mundo y que cambios ha metido en produccion para arreglarlo.
Sobre el papel todo cuadra: BLoC para el estado y Clean Architecture para separar capas. Es lo que hay en casi cualquier proyecto Flutter de tamano medio, y durante anos ha funcionado. El problema aparece cuando el repositorio pasa de las decenas de miles de lineas y varios equipos meten mano a la vez. Ahi el patron deja de sostener el edificio.
Quien escribe esto lleva siete anos arquitectando aplicaciones moviles y lo plantea sin rodeos: el fallo no esta en BLoC ni en Clean Architecture, esta en haberlos convertido en dogma en lugar de en herramientas.
Donde revienta de verdad
Tres sitios predecibles. El primero es el vertedero de providers globales: si el arbol raiz es una piramide de MultiBlocProvider envolviendo todo, estas comprando rebuilds innecesarios y fugas de memoria. El segundo es la sobreingenieria de capas. No hacen falta Entity, DTO, Model y ViewModel para una pantalla que pinta una lista de ajustes; a veces son 200 lineas de boilerplate para cambiar un nombre. El tercero es el caos asincrono: red, SQLite o Isar y WebSockets en tiempo real sin una estrategia de sincronizacion clara convierten el estado en un campo de minas de condiciones de carrera.
Que estan cambiando
Acotar el estado es el primer movimiento. Nada de lanzar todo al root: estructura por features y estados locales ahi donde importan. Da igual si tiras de BLoC con factorias gestionadas por GetIt o injectable, o si prefieres los modificadores auto-dispose de Riverpod. El objetivo es el mismo: que el recolector de basura haga su trabajo en cuanto la pantalla sale del stack de navegacion.
El segundo es dejar de sembrar bloques try-catch por todas partes. Las excepciones crudas subiendo a la capa de UI son un desastre. En su lugar, el autor aboga por manejo funcional de errores con paquetes como fpdart, o tipos Either propios. La firma tipica devuelve un Future<Either<Failure, UserProfile>>, consulta primero la cache local y solo va a red si falta. Un DioException se mapea a un ServerFailure, cualquier otra cosa a un UnexpectedFailure. La UI queda obligada a cubrir los dos caminos, exito y fallo. Se acaban las pantallas rojas porque un null se colo por donde no debia.
El tercero es modularizar antes de que sea tarde. Si los tiempos de compilacion se parecen a la pausa del cafe, el monolito es demasiado grande. Toca trocear en paquetes independientes con Melos: el design system por un lado, la capa de red por otro, y cada feature (feature_auth, feature_checkout) en su propio paquete para que la gente no se pise.
Rendimiento, aparte
Clean Architecture no salva de una UI que va a tirones. Tres comprobaciones basicas: activar prefer_const_constructors en el linter y hacerle caso de verdad, cambiar BlocBuilder gigantes por BlocSelector cuando solo se esta escuchando un booleano, y mandar a un isolate de fondo con compute() el trabajo pesado, como parsear un JSON enorme o ejecutar rutinas de cifrado.
El resumen mental que deja el autor es que la arquitectura existe para que la vida del equipo sea mas facil seis meses despues, cuando el cliente pida una reescritura gorda. Y pregunta abiertamente si sigue mereciendo la pena el layout clasico de BLoC o si toca empezar a desmontarlo.
