Límites
Toda buena arquitectura establece límites entre sus partes, evitando que sepan de su existencia entre ellos, lo cual permite aplazar decisiones, ahorrar tiempo y evitar problemas.
A partir del diagrama de ejemplo, se trazan límites que permiten diferenciar la finalidad de cada área delimitada, por lo que se distingue lo siguiente:
- Tanto la Capa de Interfaz de Usuario (Presentación) ⬇️ como la Capa de Persistencia ⬆️ apunta hacia la Capa de Lógica de Negocio.
- Para el intercambio de información, las estructuras de datos cruzan los límites. Estas estructuras de datos no deben contener dependencias que violen la regla de dependencia.
- En lugar de que la Capa de Interfaz de Usuario llame directamente al caso de uso, se propone realizarlo a través de una abstracción (Services Abstraction), que sigue un enfoque de ejecución basado en servicios.
- La Capa de Lógica de Negocio no necesita saber los detalles de implementación de las demás capas, solo expone una interfaz bien definida con los servicios que necesita, como es el caso del repositorio (Repository Abstraction).
Por lo tanto, a partir del diagrama anterior, se puede especificar cómo cruzar estos límites:
Una de las claves para lograr un cruce de límites adecuado es gestionar las dependencias del código fuente, por lo que podemos distinguir 2 formas:
| Forma 1: El flujo de control cruza el límite | Forma 2: El límite se cruza en contra del flujo de control |
|---|---|
 |
 |
| Es un cruce simple de un nivel inferior a un nivel superior. En el ejemplo, Customer solicita usar el método de la interfaz Servicio y para usarlo necesita a su vez debe conocer también a Data. | Aquí el límite se cruza contra el flujo de control donde un nivel superior necesita invocar un servicio de nivel inferior. En el ejemplo, el nivel superior declara lo que necesita y el nivel inferior lo implementa |
Aquí no se trata de que una forma sea mejor que la otra, sino de dónde es más adecuado utilizar cada una. Por ejemplo, la primera forma se puede aplicar cuando el Presenter usa los servicios de los casos de uso, mientras que la segunda forma es más apropiada para los casos de uso y la base de datos.
El flujo de control se refiere a la secuencia de instrucciones que se ejecutan en un sistema, determinando el orden y la forma en que se realizan las operaciones.
Si ejecutamos solo el código del diagrama llamado forma 2, el orden de ejecución se produce del nivel superior al nivel inferior ➡️, mientras que el cruce o la dependencia ocurre en dirección opuesta ⬅️, por eso se dice que cruzamos el límite contra el flujo de control. Asimismo, este flujo de control no toma en cuenta las interfaces debido a que, en tiempo de ejecución, estas no existen.
El uso de hilos se refiere a la utilización de subprocesos que permiten realizar tareas en paralelo, lo cual mejora el rendimiento y la capacidad de respuesta de la aplicación. Es perfectamente válido que el uso de subprocesos esté presente tanto en un solo componente como distribuido en varios componentes, ya que no representa límites arquitectónicos.
Por ejemplo, en Java se proporciona soporte integrado para la concurrencia y el manejo de hilos a través de la clase Thread y otras clases relacionadas, como Executor, ThreadPoolExecutor, Future, CompletableFuture, etc
