Change Locality, o Localidad de Cambio, es un principio de diseño que postula que los elementos de un sistema de software que son propensos a cambiar juntos, o por la misma razón, deben residir juntos. Esto implica que las modificaciones a una funcionalidad específica o a un concepto de negocio no deberían requerir cambios dispersos a través de múltiples módulos, capas o servicios. En cambio, todos los componentes afectados por un cambio particular deberían estar encapsulados o co-localizados, facilitando así la identificación, implementación, prueba y despliegue de las modificaciones.
Este principio se manifiesta en la práctica a través de diversas arquitecturas y patrones de diseño. En el desarrollo de microservicios, por ejemplo, un servicio bien diseñado exhibe alta Change Locality si todos los cambios relacionados con su dominio de negocio se contienen dentro de sus límites, sin afectar a otros servicios. En bases de datos, la organización de tablas y vistas para que las operaciones de una entidad de negocio se agrupen puede mejorar la Change Locality. En sistemas de control de versiones, la agrupación de archivos relacionados en un mismo directorio o repositorio puede reflejar este principio. Herramientas de análisis de código como 'hotspot analysis' en Git (ej. 'git blame', 'git log -p') pueden revelar áreas con baja Change Locality, indicando módulos que cambian frecuentemente junto con otros no relacionados.
Para el arquitecto, la Change Locality es crucial para diseñar sistemas resilientes, mantenibles y escalables. Un sistema con alta Change Locality reduce el riesgo de efectos secundarios no deseados, simplifica la refactorización y acelera el tiempo de comercialización de nuevas características. Los trade-offs incluyen la posible duplicación de código o datos en sistemas distribuidos para lograr una mayor autonomía de los servicios (y, por ende, mayor Change Locality), o la necesidad de una comprensión profunda del dominio para agrupar correctamente las responsabilidades. Ignorar este principio puede llevar a 'cambios de escopeta' (shotgun surgery), donde una pequeña modificación requiere tocar múltiples partes del sistema, aumentando la complejidad, el riesgo de errores y el tiempo de desarrollo. Priorizar la Change Locality es una decisión estratégica que impacta directamente la agilidad y la sostenibilidad a largo plazo de una arquitectura.