Subdirección de las Tecnologías de la Información y Comunicaciones
Área de Gobernanza y Calidad
Versión
Tabla de Contenido
Cumplimiento normativo
Las normas expuestas son de obligado cumplimiento. La STIC podrá estudiar los casos excepcionales los cuales serán gestionados a través de los responsables del proyecto correspondiente y autorizados por el Área de Gobernanza de la STIC. Asimismo cualquier aspecto no recogido en estas normas deberá regirse en primera instancia por las guías técnicas correspondientes al esquema nacional de seguridad y esquema nacional de interoperabilidad según correspondencia y en su defecto a los marcos normativos y de desarrollo software establecidos por la Junta de Andalucía, debiendo ser puesto de manifiesto ante la STIC. La STIC se reserva el derecho a la modificación de la norma sin previo aviso, tras lo cual, notificará del cambio a los actores implicados para su adopción inmediata según la planificación de cada proyecto. En el caso de que algún actor considere conveniente y/o necesario el incumplimiento de alguna de las normas y/o recomendaciones, deberá aportar previamente la correspondiente justificación fehaciente documentada de la solución alternativa propuesta, así como toda aquella documentación que le sea requerida por la STIC para proceder a su validación técnica. Contacto Arquitectura: l-arquitectura.stic@juntadeandalucia.es |
Histórico de cambios
Los cambios en la normativa vendrán acompañados de un registro de las modificaciones. De este modo se podrá realizar un seguimiento y consultar su evolución. Ordenándose de mas recientes a menos recientes, prestando especial cuidado a las cabeceras de la tablas dónde se indican las fechas de entrada en vigor y versión.
|
2 Introducción
Clean Architecture, es una arquitectura de software que enfatiza la separación de responsabilidades y el desacoplamiento de componentes. Su objetivo principal es crear sistemas que sean fáciles de mantener, testear y evolucionar. Con estas características se busca crear sistemas modulares, altamente mantenibles y adaptables al cambio. Al definir claras separaciones de responsabilidades y establecer flujos de dependencia unidireccionales, se promueve un diseño de software robusto y flexible que puede evolucionar con los requisitos del negocio y la tecnología.
Principales Características de la Clean Architecture
Independencia de la Framework: - La lógica del negocio y las reglas de la aplicación no deben depender de ninguna tecnología específica de framework. Esto facilita cambiar de frameworks sin afectar la lógica del negocio.
Testabilidad: - Al mantener la lógica del negocio independiente de los detalles de implementación, se facilita la creación de pruebas unitarias y de integración. Los componentes pueden ser probados en aislamiento.
Independencia de la Interfaz de Usuario: - Las reglas del negocio no dependen de la interfaz de usuario, lo que permite cambiar de tecnologías de interfaz de usuario (por ejemplo, de web a móvil) sin cambiar la lógica del negocio.
Independencia de la Base de Datos: - La lógica del negocio no debe depender de los detalles de la base de datos. Esto permite cambiar de sistemas de base de datos sin afectar la lógica del negocio.
Independencia de Agencias Externas: - La arquitectura debe ser independiente de bibliotecas externas. Si una biblioteca debe cambiar, solo debe afectar una parte mínima del sistema.
Componentes y Capas
Entidades de dominio: - Contienen las reglas del negocio más generales y de más alto nivel. Estas reglas de negocio pueden ser compartidas por diferentes aplicaciones en el mismo dominio.
Casos de Uso: - Contienen la lógica de aplicación específica para un caso de uso particular. Orquestan el flujo de datos hacia y desde las entidades y dirigen a los actores externos (interfaces de usuario, dispositivos, etc.).
Interfaces de Controladores y Presenters: - Interfaces que definen cómo se debe interactuar con los casos de uso y cómo presentar los resultados. Estas interfaces ayudan a desacoplar las implementaciones concretas de los controladores y presenters de los casos de uso.
Adaptadores (Interfaces de usuario, Gateways, Presenters, etc.): - Implementaciones concretas de los controladores, presenters y gateways. Aquí es donde los detalles específicos de la tecnología (como frameworks web, mensajería, bases de datos, etc.) se manejan.
Infraestructura: - Contiene detalles técnicos concretos como la persistencia de datos (repositorios concretos), la configuración del framework, y otros aspectos técnicos necesarios para que la aplicación funcione.
Flujo de Dependencias
- Las dependencias deben fluir desde los niveles más externos hacia los más internos.
- Las capas más externas (adaptadores e infraestructura) pueden depender de las capas más internas (casos de uso y entidades), pero no al revés.
- Se utilizan interfaces para definir contratos en las capas internas, permitiendo que las capas externas proporcionen implementaciones concretas sin que las capas internas sean conscientes de estos detalles.
3 Arquitecturas Limpias dentro del SAS
Pauta | Descripción | Regla de verificación |
|---|---|---|
P1 | Dependencias Top-Down. Como se indica en el gráfico las dependencias deben seguir un flujo top-down de tal forma que las capas superiores deben tener dependencia con la inmediatemente inferior y con el dominio. | Revisando las dependencias del gestor de paquete (Maven, Nuget, npm) |
| P2 | Independencía de tecnología. Las capas del kernel (Dominio y aplicación) deben ser desarrolladas sin ningún conocimiento tecnológico que no sea inherente al dominio. | Revisando las dependencias del gestor de paquete (Maven, Nuget, npm) |
| P3 | Independencía de Frameworks. Se debe evitar el uso de frameworks en capas interiores de la arquitectura, permitiendo un substitución sin efectos colaterales | Revisando las dependencias del gestor de paquete (Maven, Nuget, npm) |
| P4 | Testable. las reglas de negocio son fácilmente testables sin utilizar la interfaz de usuario, base de datos, servidor web | Revisando las dependencias del gestor de paquete (Maven, Nuget, npm). Existencia de test unitarios que no necesiten configuración tecnológica |
| P5 | Independiente de la interfaz de usuario. La interfaz de usuario es fácilmente sustituible o las nuevas versiones del framework de UI que usas tienen un impacto mínimo. | En thin server, la UI debe ser un proyecto a parte siguiendo la normativa front |
| P6 | La estructura del microservicio debe estar basada en el arquetipo proporcionado desde la STIC | La estructura de carpetas y módulos corresponde con la misma que se define en el arquetipo |
Referencias
En esta sección se presentará un listado de bibliografia o documentos externos que sean de ayuda para la compresión de la normativa expuesta. Si no se expone información en esta sección eliminese. Esta nota informativa debe ser eliminada en el documento normativo definitivo. |