Granularity
Granularity de qué
Granularity describe qué tan gruesas o finas son las unidades arquitectónicas relevantes para una decisión o vista. Necesita identificar la unidad, su alcance y el marco de comparación. Hablar de «granularidad fina» sin decir de qué deja abierta la pregunta importante.
Puede interesar la granularidad de components, módulos, servicios, unidades de deployment, autoridad sobre datos, transacciones, interfaces o capacidad ampliable. Esos cortes pueden diferir dentro del mismo sistema. Aquí usamos coarse y fine de forma relativa, sin una escala universal de tamaños.
En Commerce, Payments puede ser una unidad amplia respecto de Authorization, Capture, Refund y Settlement, y una unidad fina respecto de toda Commerce Platform. Ninguna de esas comparaciones dice todavía si Payments tiene buenos límites o si debe ejecutarse remotamente.
El SEI ilustra una descomposición de módulos con distintos niveles y explica que módulos y capas pueden cruzarse sin ser idénticos. Esa diferencia respalda declarar qué estructura observamos antes de comparar unidades. Software Architecture Documentation in Practice: Documenting Architectural Layers, sección 2.7.
Granularity y Decomposition
decomposition pregunta qué unidades y fronteras establecemos y por qué. Granularity examina el alcance relativo de esas unidades. Cambiar la descomposición puede cambiar granularidad; los conceptos no son sinónimos.
Una alternativa divide Commerce en Orders, Payments, Inventory y Shipping. Otra distingue dentro de Payments autorización, captura, reembolso y liquidación. Ambas son decisiones de descomposición. La segunda presenta unidades más finas para ciertas responsabilidades de pago, pero necesita justificar qué límites conserva o introduce.
Es posible revisar granularidad sin convertir inmediatamente cada parte identificada en unidad externa. Refinar Payments en una vista de análisis ayuda a comprender su interior; decidir deployment o ownership separado requiere otro razonamiento. Más detalle en un documento tampoco prueba que el sistema construido tenga más fronteras efectivas.
modularity pregunta cómo esas unidades encapsulan decisiones y controlan interacción. Un Payments amplio puede ser modular; varias unidades pequeñas pueden compartir internals y cambiar siempre juntas. Tamaño relativo y calidad de relaciones son propiedades distintas.
Finer y coarser: oportunidades y costos
Un corte más fino puede localizar responsabilidad, cambio, ownership, deployment, scaling o contención de efectos. Esas oportunidades necesitan contratos, capacidad operacional y mecanismos adecuados. Separar nombres o archivos no materializa automáticamente independencia.
Puede también multiplicar interacciones, versiones, observación y caminos de fallo. Una nueva regla de autorización que atraviesa varias unidades quizá requiera coordinación antes innecesaria. Si las unidades siguen entregándose y ampliándose juntas, hay que explicar qué valor aporta la nueva frontera.
| Corte relativo | Beneficio posible | Costo que conviene observar |
|---|---|---|
| Más fino | Cambio localizado en una responsabilidad. | Contratos y compatibilidad entre participantes. |
| Más fino | Capacidad o contención más específica. | Recursos comunes y nuevas rutas de fallo. |
| Más grueso | Colaboración local y menor superficie operativa. | Cambio, entrega o capacidad compartidos. |
| Más grueso | Invariantes más fáciles de mantener localmente. | Autoridad amplia y menor autonomía de algunas partes. |
Un corte más grueso puede reducir fronteras que deben cruzarse, permitir transacciones locales y facilitar diagnóstico. Puede también ampliar el alcance de un cambio, una entrega o un fallo. accidental-complexity permite preguntar qué trabajo introduce ese corte y qué necesidad lo justifica, tanto en unidades finas como amplias. Coarse no significa malo, y fine no significa mejor: importa qué consecuencias satisfacen los drivers actuales.
Granularidad lógica y de deployment
deployment examina qué se instala, actualiza o revierte como unidad. Su granularidad puede diferir de la organización de responsabilidades. Veinte módulos podrían entregarse en una aplicación, y cinco capacidades podrían corresponder a cinco unidades instalables.
La relación tampoco tiene que ser uno a uno. Una capacidad Payments puede realizarse mediante API, worker de conciliación y batch de liquidación entregados por separado. Ese empaquetado no demuestra tres autoridades comerciales diferentes ni exige que todo consumidor conozca las tres realizaciones.
El SEI relaciona deployability con granularidad, control y eficiencia de entrega, y distingue la estructura de servicios del proceso de desplegarlos. Usamos esa distinción para evaluar independencia efectiva, no para deducirla del número de artifacts. Two Categories of Architecture Patterns for Deployability.
Un repositorio puede contener múltiples unidades entregables; varios repositorios pueden necesitar un release coordinado. Contar repositorios, proyectos o pipelines no describe por sí solo la granularidad arquitectónica pertinente.
Granularidad de Scaling e Isolation
scaling pregunta qué capacidad puede cambiar independientemente y qué recurso la aporta. Replicar toda una aplicación aumenta una unidad gruesa de capacidad. Ajustar worker pools específicos dentro de un deployment puede permitir un control más fino sobre ciertos recursos sin cambiar el artefacto instalado.
Los pools pueden seguir compartiendo CPU, memoria o storage. Aumentar concurrencia de autorización no garantiza throughput mayor si el proveedor contractual limita llamadas. Hay que observar el cuello de botella y las dependencias antes de prometer que un corte fino escala mejor.
isolation examina qué efectos quedan contenidos. Un módulo lógico pequeño que comparte proceso y conexiones puede conservar una frontera gruesa de fallo de runtime. Una unidad remota puede tener contención específica y depender del mismo servidor de datos que otras.
Granularidad lógica, de instalación, de capacidad y de contención pueden coincidir, pero no se presuponen iguales. La comparación necesita identificar qué mecanismo cambia y qué permanece compartido.
Ownership, invariantes y coordinación
data-ownership delimita autoridad sobre información. Dividirla demasiado finamente puede producir invariantes entre owners, replicación y reconciliación. Agruparla demasiado puede concentrar autoridad y dificultar autonomía o cambios localizados. El tamaño adecuado depende de responsabilidades reales.
En Inventory, reservar existencias y proteger la cantidad disponible pueden formar una obligación conjunta. Si reserva y stock pasan a authorities independientes con almacenamiento y confirmación separados, una operación antes local puede convertirse en un problema de coordination entre participantes.
No basta conservar la fórmula comercial en ambos servicios. Hay que decidir quién autoriza la reserva, qué confirma cada resultado y cómo se recupera un estado parcial. La frontera desplaza obligaciones; no elimina la necesidad de mantener el compromiso.
Separar módulos dentro de una misma transacción disponible no produce automáticamente ese problema distribuido. La consecuencia depende de autoridad, confirmación y recursos, además del nivel de detalle elegido. Por eso conviene evaluar un cambio de frontera con un escenario concreto.
Communication y superficie operacional
communication examina cómo colaboran las unidades. Un corte de runtime más fino puede aumentar intercambios y dependencias temporales. Módulos lógicos finos dentro del mismo proceso pueden continuar usando llamadas locales, sin incorporar una red entre cada responsabilidad.
Fowler explica que distribución agrega latencia y fallos, y que agrupar interacciones puede reducir llamadas a costa de cambiar el modelo de programación. La distinción útil aquí es entre granularidad de unidades y granularidad de operaciones expuestas: no siempre cambian juntas. Microservice Trade-Offs, Distribution.
Si Orders necesita llamadas sucesivas para reconstruir una decisión privada de Payments, reducir el tamaño de servicios puede aumentar conversación sin mejorar límites. Tal vez convenga una capacidad pública más significativa, mantener partes juntas o revisar el reparto de responsabilidad.
Más unidades operativas también pueden requerir observación por versión, atribución de fallos y procedimientos adicionales. La comparación debe incluir ese trabajo, no solamente líneas de código trasladadas a otro proyecto.
Profiles muestran tendencias
monolith puede contener muchos components: una unidad amplia de entrega no significa una única responsabilidad arquitectónica. modular-monolith permite granularidad lógica fina con deployment común, conservando costos y recursos compartidos.
service-based-architecture agrupa servicios relativamente amplios en ciertas variantes. No es «microservices mal dimensionados». service-oriented-architecture necesita declarar el alcance de sus capacidades e integraciones; el nombre no establece un tamaño único.
microservices tampoco significa crear los servicios más pequeños posibles. Lewis y Fowler señalan que el nombre ha inducido una atención excesiva al tamaño y describen variación entre sistemas reales. Su discusión no proporciona un umbral universal de líneas, personas o endpoints. Microservices: How big is a microservice?.
Los profiles reúnen decisiones sobre varios ejes. Granularity ayuda a preguntar qué responsabilidades y consecuencias corresponden a cada unidad, sin identificar el perfil mediante un conteo.
architectural-quantum [ADVANCED] agrega condiciones de independencia, cohesión y coupling para examinar un alcance arquitectónico. Puede informar una decisión de tamaño, pero no reemplaza Granularity ni prescribe unidades más pequeñas.
Commerce: mantener Payments o refinarlo
Mantener Payments como unidad puede facilitar una política coherente de autorización, captura y reembolso, con internals protegidos para Orders. Subdividirlo puede ayudar si esas responsabilidades presentan necesidades diferentes de cambio, capacidad o entrega.
En ambas alternativas, boundaries debe precisar autoridad y accesos; interfaces debe expresar capacidades sin revelar cada paso interno. Una descomposición más fina puede mantener buenos límites y también introducir obligaciones adicionales de coordinación.
Si las partes se despliegan separadamente pero cambian en lockstep, comparten representaciones privadas y necesitan todas las demás disponibles para progresar, la independencia esperada necesita revisión. La separación conserva coupling y agrega costos remotos. Esa observación describe consecuencias, no una descalificación del equipo.
Cambio, equipos y razonamiento
modifiability permite evaluar un cambio concreto y su propagación. evolvability examina adaptación sostenida. Los patrones de cambio pueden orientar límites, pero «un cambio esperado, un servicio» sería una regla demasiado rígida: los cambios se superponen y evolucionan.
Una unidad muy amplia puede superar el alcance que un equipo comprende y opera. Muchas unidades diminutas pueden exigir coordinación excesiva entre equipos. Es una influencia organizacional relevante, no una receta de diseño de organizaciones.
Preguntar qué cambia junto, qué debe mantenerse consistente, qué requiere entrega o capacidad independiente y qué fallos importa contener. Contrastar esas necesidades con comunicación, ownership y operación introducidos por separar. Las respuestas orientan una decisión revisable; no se suman en un score.
Errores de interpretación
Coarse no significa monolith, y más servicios no significa granularidad adecuada. Tampoco cada bounded context, módulo u operación debe corresponder a un servicio o deployment. La correspondencia necesita un motivo y consecuencias explícitas.
Las líneas de código pueden ayudar a observar volumen de implementación, pero no delimitan responsabilidad, autoridad ni interacción. La pregunta útil sigue siendo «granularity de qué y respecto de qué alternativa», con evidencia del cambio, invariante o carga que interesa atender.