Transición
Todos los diagramas anteriores basados en capas ayudan a entender el propósito y la interacción de cada nivel en un arquitectura; sin embargo, para lograr una representación más apropiada de la arquitectura de un sistema, se requiere emplear un enfoque basado en componentes. De hecho, la descomposición en capas de presentación, dominio y persistencia, pueden ser vistos como componentes.
Para definir qué son los componentes, podemos recurrir a las siguientes citas:
Los componentes son las unidades de despliegue. Son las entidades más pequeñas que pueden desplegarse como parte de un sistema. En Java, son archivos jar.
- Robert C. Martin (Uncle Bob), Clean Architecture: A Craftsman’s Guide to Software Structure and Design, 2017
Una agrupación de funcionalidades relacionadas detrás de una interfaz limpia y agradable, que reside dentro de un entorno de ejecución como una aplicación.
- Simon Brown(Author of the C4 Model), Clean Architecture: A Craftsman’s Guide to Software Structure and Design, 2017
Por otro lado, mi definición de componente no se aleja mucho de la idea central de los conceptos anteriores y se relaciona en parte con los conceptos que proporciona UML. Es así que lo defino de la siguiente manera:
Un componente es una unidad autónoma y reemplazable que encapsula la funcionalidad de una parte específica del sistema.
Me gusta referirme a los componentes como el acrónimo ARE, por lo que los llamo "Componentes ARE" 🤭. El motivo se debe a que un enfoque basado en componentes significa:
- Autonomía: Porque tiene la capacidad de funcionar y ser probado de manera independiente.
- Reutilización: Porque puede ser usado en múltiples contextos y aplicaciones, sin necesidad de modificaciones significativas.
- Encapsulación: Porque oculta su implementación interna y expone sus servicios al consumidor a través de interfaces bien definidas.
Estos componentes, siempre que sea posible, definen los servicios que ofrecen a sus consumidores a través de interfaces proporcionadas y también pueden especificar los servicios que requieren a través de interfaces requeridas. Asimismo la regla de dependencia continúa vigente, tanto en las relaciones entre los componentes (conociendo el rol de cada componente en el sistema) como en la organización interna de cada componente (manteniendo la separación de preocupaciones).
