El principio Abierto-Cerrado (OCP) - Clean Architecture

Según estableció Bertrand Meyer en 1988  el principio de abierto-cerrado o The Open Closed Principle (OCP):

«A software artifact should be open for extension but closed for modification.»

Esto viene a decir que el sistema de software debería poder añadir nuevos requisitos sin tener que modificar el sistema actual.

Si pequeños cambios requieren de un gran esfuerzo para modificar el software entonces es que los arquitectos de software no están tomando buenas decisiones.

Para poder llevar el principio a cabo se tiene que organizar las dependencias del código de manera que se pueda asegurar que los cambios en una de las responsabilidades no impacten en otras. Esta organización debería asegurar que el comportamiento puede extender sin hacer una modificación.

Para llevar esto a cabo se particionan los procesos en clases y separar estas clases en componentes.

Lo primero que se debería plantear a la hora de diseñar un sistema son las dependencias de código. Los distintos componentes van a estar relacionados entre sí aunque estas relaciones deberían ser unidireccionales. Eso significa que si el el componente A debería ser protegido de los cambios en el componente B entonces el componente B debería depender del componente A.

Las reglas de negocio deberían estar en un componente protegidos por lo que que no deberían depender de ningún otro.

Por ejemplo, si tenemos un sistema el cual requiere de un registro de usuarios y este registro de usuarios tiene unas determinadas reglas (las reglas de negocio) estas se pueden modelizar en un componente. Este componente se puede nombrar «CreateUserService». Las reglas de negocio establecen, entre varias requisitos, que se debe enviar una notificación por email.

En este caso, el cómo se manden las notificaciones por email no pertenece a las reglas de negocio si no que es más bien un concepto más externo. Podría mandarse de forma local o utilizar un servicio de terceros. Para proteger las reglas de negocio de un posible cambio en la manera de enviar los emails se crea una dependencia de manera que los cambios en las notificaciones por email no afectan a las reglas de negocio.

En el siguiente diagrama se puede apreciar como el componente «CreateUserService» tiene una dependencia de un «EmailNotifications», el cual puede puede inyectarse ya sea con «LocalEmailNotifications» para mandar las notificaciones de forma local o «MandrillEmailNotifications» para mandarlos a través de un tercero.

Esta estrategia crea una jerarquía de protección basada en la noción de nivel. Las reglas de negocio son el nivel más alto y las más protegidas. Otros componentes como vistas, controladores, el sistema de persistencia o servicios de terceros dependen de estas reglas de negocio.

Conclusión

El objetivo de este principio es hacer el sistema más fácil de ampliar sin incurrir en un alto impacto de cambio. La meta es dividir el sistema en componentes y ordenar estos componentes en una jerarquía de dependencias que protege los componentes de alto nivel de los cambios en los niveles más bajos.