Subdirección de las Tecnologías de la Información y Comunicaciones
Área de Gobernanza y Calidad
Versión
SECCIÓN DE CONTENIDO
Modificar el name de la versión para que enlace a la versión correspondiente del documento (definida en el TOC)
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.
1. Introducción
Un microfrontend es:
- Un componente visual que está desarrollada, implementada y gestionada de forma independiente.
- Permiten dividir una aplicación web en varias partes más pequeñas, cada una de las cuales puede tener su propio ciclo de vida, stack tecnológico, y equipo de desarrollo.
- Es responsable de una funcionalidad o una sección específica de la interfaz de usuario y se integra con otras partes de la aplicación para formar una experiencia de usuario cohesiva.
- La comunicación será la estándar para los componentes web
1.1. Ámbito de aplicación.
Ámbito de aplicación obligatorio (*) Esta arquitectura de referencia será de aplicación obligatoria(*) en los siguientes casos:
|
|---|
Se recomienda su aplicación:
- Sistemas comerciales que permitan una arquitectura tecnológica flexible y alineada con este modelo de referencia.
- Desarrollos locales con previsión de escalar a sistemas corporativos.
- Cualquier desarrollo para implementar nuevos procesos sobre los sistemas de información existentes.
Se recomienda analizar en detalle con la unidad de Arquitectura de la STIC y particularizarla para los siguientes casos:
- Sistemas analíticos o que gestionen grandes volúmenes de datos (**).
1.2. Ciclo de vida de la arquitectura de referencia
Los cambios normativos dentro de la arquitectura de referencia seguirán el siguiente ciclo de vida:
- Pre-release: Periodo durante el cual la normativa se hace publica aunque no es necesario adherirse inmediatamente. En este periodo aún puede sufrir pequeñas correcciones.
- Adopción : Periodo durante el cual la normativa inicia un periodo de tiempo flexible para su aplicación de forma obligatoria al ámbito en el cual está destinado.
- Activa: Periodo durante el cual es obligatorio su cumplimiento para el ámbito en el cual está destinado.
- Retiro: Periodo durante el cual dejará de aplicarse en el ámbito al cual está destinado en sustitución de nuevas versiones o normas.
(*) Cualquier propuesta que difiera de esta arquitectura deberá ser aprobada por el Área de Gobernanza de la STIC, previa solicitud y justificación en su caso.
(**) En proceso de elaboración de una arquitectura de referencia para sistemas analíticos y big data.
Arquitectura
Enrutamiento (Interno y Dinámico)
👮 Pauta | 📖 Descripción | 🕵️ Verificación |
|---|---|---|
ENR-P1 | Se hará uso de la librería @sas/lib-stic-route que se puede descargar del repositorio de artefactos | Revisión de código |
ENR-P2 | La navegación será siempre interna | Test unitario |
| ENR-P3 | El microfrontend debe proporcionar una constante con una lista de los paths disponibles | Test unitario |
| ENR-P4 | El microfrontend debe proporcionar un método métodos para construir los paths con variables | Test unitario |
| ENR-P5 | El microfrontend debe proporcionar en la documentación los paths disponibles juntos con sus variables | Revisión de documentación |
ED-excepción ALERTA | En caso de necesitar enrutamiento externo (URL) deberá ser justificada y previamente validada por la oficina de arquitectura creando un ticket Jira de decisión técnica (Tarea genera → tipo: decisión → subtipo: técnica) en el proyecto y asignársela al responsable del departamento LUIS MARTINEZ FONTIVEROS | N/A |
Comunicación (Host- Fragment)
👮 Pauta | 📖 Descripción | 🕵️ Verificación |
|---|---|---|
COM-P1 | La comunicación entre el host y un MFE deberá ser la estándar en el desarrollo de componentes, propiedades hacia abajo, eventos hacia arriba. Para más detalle consultar nota aclaratoria | Revisión de código |
COM-P2 | Deberá estar documentada la api de integración con el MFE (propiedades y eventos) | Revisión de documentación |
| COM-P3 | La comunicación entre dos MFE, deberá ser orquestado por el Host | Revisión de código |
ED-excepción ALERTA | En caso de necesitar otro mecanismo de comunicación como buses de eventos compartidos, cookies o IndexedDB deberá ser justificada y previamente validada por la oficina de arquitectura creando un ticket Jira de decisión técnica (Tarea genera → tipo: decisión → subtipo: técnica) en el proyecto y asignársela al responsable del departamento LUIS MARTINEZ FONTIVEROS | N/A |
Nota Aclaratoria
the component shouldn't change its own public properties, except in response to user input. For example, a menu component might have a public
selected property that can be initialized to a given value by the owner of the element, but that is updated by the component itself when the user selects an item. In these instances, the component should dispatch an event to indicate to the component's owner that the selected property changed. See Dispatching events for more details.Integración-Directa (Host-Fragment)
👮 Pauta | 📖 Descripción | 🕵️ Verificación |
|---|---|---|
COM-AIS-P1 | La comunicación entre el host y un MFE deberá ser la estándar en el desarrollo de componentes, propiedades hacia abajo, eventos hacia arriba. Para más detalle consultar nota aclaratoria |
|
COM-AIS-P2 | Deberá estar documentada la api de integración con el MFE (propiedades y eventos) |
|
| COM-AIS-P3 | La comunicación entre dos MFE root, deberá ser orquestado por el Host | |
| COM-AIS-P4 | Consultar documentación para un correcto uso de los recursos de integración | |
ED-excepción ALERTA | En caso de necesitar otro mecanismo de comunicación como buses de eventos compartidos, cookies o IndexedDB deberá ser justificada y previamente validada por la oficina de arquitectura creando un ticket Jira de decisión técnica (Tarea genera → tipo: decisión → subtipo: técnica) en el proyecto y asignársela al responsable del departamento LUIS MARTINEZ FONTIVEROS |
Integración-Aislada (Host- IsolatedFragment)
👮 Pauta | 📖 Descripción | 🕵️ Verificación |
|---|---|---|
COM-AIS-P1 | La comunicación entre el host y un MFE deberá ser la estándar en el desarrollo de componentes, propiedades hacia abajo, eventos hacia arriba. Para más detalle consultar nota aclaratoria |
|
COM-AIS-P2 | Deberá estar documentada la api de integración con el MFE (propiedades y eventos) |
|
| COM-AIS-P3 | La comunicación entre dos MFE root, deberá ser orquestado por el Host | |
| COM-AIS-P4 | Consultar documentación para un correcto uso de los recursos de integración | |
ED-excepción ALERTA | En caso de necesitar otro mecanismo de comunicación como buses de eventos compartidos, cookies o IndexedDB deberá ser justificada y previamente validada por la oficina de arquitectura creando un ticket Jira de decisión técnica (Tarea genera → tipo: decisión → subtipo: técnica) en el proyecto y asignársela al responsable del departamento LUIS MARTINEZ FONTIVEROS |
Gestión de Estado Compartido
👮 Pauta | 📖 Descripción | 🕵️ Verificación |
|---|---|---|
CV-P1 | El control de versiones estará regido por las pautas marcadas por Semantic Version. Mayor.Minor.Patch |
|
CV-P2 | Patch: Indica correcciones sobre la funcionalidad de la versión |
|
| CV-P3 | Minor: Indica nuevas funcionalidades que son retrocompatibles, es decir, no existen eliminaciones o actualizaciones en el contrato de integración (api del componente). Los añadidos en el contrato que mantengan la retrocompatibilidad están permitidos. | |
| CV-P4 | Mayor: Indica nuevas funcionalidades que no son retrocompatibles (breaking changes). Existe eliminación o actualización de elementos del contrato de integración (api del componente) | |
| CV-P5 | Cualquier elemento que se desee eliminar deberá ser marcado como deprecado en la versión mayor actual e indicar la alternativa a utilizar que mantiene la funcionalidad y a partir de que mayor está versión será eliminada | |
| CV-P6 | Todas las dependencias del MFE deben ser cargadas desde el CDN del SAS. | |
| CV-P7 | Todas las dependencias deben ser definidas en un script de importmap | |
| CV-P8 | El script de importmap deberá ser inyectado en el index.html del MFE en la fase de construcción, con la combinación necesaria de los importmap.json publicados en el CDN | |
ED-excepción ALERTA | En caso de necesitar que alguna dependencia no sea cargada desde el CDN del SAS y quiera ser bundleizada deberá ser justificada y previamente validada por la oficina de arquitectura creando un ticket Jira de decisión técnica (Tarea genera → tipo: decisión → subtipo: técnica) en el proyecto y asignársela al responsable del departamento LUIS MARTINEZ FONTIVEROS |
Control de Versiones
👮 Pauta | 📖 Descripción | 🕵️ Verificación |
|---|---|---|
CV-P1 | El control de versiones estará regido por las pautas marcadas por Semantic Version. Mayor.Minor.Patch |
|
CV-P2 | Patch: Indica correcciones sobre la funcionalidad de la versión |
|
| CV-P3 | Minor: Indica nuevas funcionalidades que son retrocompatibles, es decir, no existen eliminaciones o actualizaciones en el contrato de integración (api del componente). Los añadidos en el contrato que mantengan la retrocompatibilidad están permitidos. | |
| CV-P4 | Mayor: Indica nuevas funcionalidades que no son retrocompatibles (breaking changes). Existe eliminación o actualización de elementos del contrato de integración (api del componente) | |
| CV-P5 | Cualquier elemento que se desee eliminar deberá ser marcado como deprecado en la versión mayor actual e indicar la alternativa a utilizar que mantiene la funcionalidad y a partir de que mayor está versión será eliminada | |
| CV-P6 | Todas las dependencias del MFE deben ser cargadas desde el CDN del SAS. | |
| CV-P7 | Todas las dependencias deben ser definidas en un script de importmap | |
| CV-P8 | El script de importmap deberá ser inyectado en el index.html del MFE en la fase de construcción, con la combinación necesaria de los importmap.json publicados en el CDN | |
ED-excepción ALERTA | En caso de necesitar que alguna dependencia no sea cargada desde el CDN del SAS y quiera ser bundleizada deberá ser justificada y previamente validada por la oficina de arquitectura creando un ticket Jira de decisión técnica (Tarea genera → tipo: decisión → subtipo: técnica) en el proyecto y asignársela al responsable del departamento LUIS MARTINEZ FONTIVEROS |
Seguridad
👮 Pauta | 📖 Descripción | 🕵️ Verificación |
|---|---|---|
CV-P1 | El control de versiones estará regido por las pautas marcadas por Semantic Version. Mayor.Minor.Patch |
|
CV-P2 | Patch: Indica correcciones sobre la funcionalidad de la versión |
|
| CV-P3 | Minor: Indica nuevas funcionalidades que son retrocompatibles, es decir, no existen eliminaciones o actualizaciones en el contrato de integración (api del componente). Los añadidos en el contrato que mantengan la retrocompatibilidad están permitidos. | |
| CV-P4 | Mayor: Indica nuevas funcionalidades que no son retrocompatibles (breaking changes). Existe eliminación o actualización de elementos del contrato de integración (api del componente) | |
| CV-P5 | Cualquier elemento que se desee eliminar deberá ser marcado como deprecado en la versión mayor actual e indicar la alternativa a utilizar que mantiene la funcionalidad y a partir de que mayor está versión será eliminada | |
| CV-P6 | Todas las dependencias del microfrontend deben ser cargadas desde el CDN del SAS. | |
| CV-P7 | Todas las dependencias deben ser definidas en un script de importmap | |
| CV-P8 | El script de importmap deberá ser inyectado en el index.html del microfrontend en la fase de construcción, con la combinación necesaria de los importmap.json publicados en el CDN | |
ED-excepción ALERTA | En caso de necesitar que alguna dependencia no sea cargada desde el CDN del SAS y quiera ser bundlelizada deberá ser justificada y previamente validada por la oficina de arquitectura creando un ticket Jira de decisión técnica (Tarea genera → tipo: decisión → subtipo: técnica) en el proyecto y asignársela al responsable del departamento LUIS MARTINEZ FONTIVEROS |
Tema y Estilos Compartidos
👮 Pauta | 📖 Descripción | 🕵️ Verificación |
|---|---|---|
TEC-P1 | El MFE deberá ser desarrollado estilísticamente en base a las pautas definidas en el sistema de diseño |
|
TEC-P2 | El MFE deberá ser desarrollado haciendo uso del catálogo de componentes de la STIC, que estarán acordes a lo definido en el sistema de diseño |
|
TEC-P3 | El MFE deberá ser desarrollado haciendo uso de las variables expuestas por el componente del stic-theme | |
TEC-P4 | El MFE NO deberá instanciar el componente de theming. | |
TEC-P5 | El host es el responsable de instanciar el theming del que se nutrirá el MFE | |
ED-excepción ALERTA | En caso de necesitar un framework de desarrollo diferente al normativizado deberá ser justificada y previamente validada por la oficina de arquitectura creando un ticket Jira de decisión técnica (Tarea genera → tipo: decisión → subtipo: técnica) en el proyecto y asignársela al responsable del departamento LUIS MARTINEZ FONTIVEROS |
Compatibilidad con Múltiples Frameworks
👮 Pauta | 📖 Descripción | 🕵️ Verificación |
|---|---|---|
CMF-P1 | El host-legacy no tiene restricciones de tecnología |
|
CMF-P2 | El host nuevo deberá ser desarrollado exclusivamente en Lit |
|
CMF-P3 | Los MFE deberán ser realizados exclusivamente en Lit | |
CMF-P4 | Todas las dependencias del MFE deben ser cargadas desde el CDN del SAS. | |
CMF-P5 | Todas las dependencias deben ser definidas en un script de importmap | |
CMF-P4 | El script de importmap deberá ser inyectado en el index.html del MFE en la fase de construcción, con la combinación necesaria de los importmap.json publicados en el CDN | |
ED-excepción ALERTA | En caso de necesitar una especialización de los estilos no contemplada en el sistema de diseño y/o en el theme de la STIC, deberá ser justificada y previamente validada por la oficina de arquitectura creando un ticket Jira de decisión técnica (Tarea genera → tipo: decisión → subtipo: técnica) en el proyecto y asignársela al responsable del departamento LUIS MARTINEZ FONTIVEROS |
Tolerancia a Fallos
| 👮 Pauta | 📖 Descripción | 🕵️ Verificación |
|---|---|---|
Estado del documento
| Concepto a Desarrollar | Estado | POC |
|---|---|---|
Enrutamiento (Interno, Dinámico) | DEFINIDO | REALIZADA |
Comunicación (Host- MFE / MFE-MFE) | DEFINIDO | REALIZADA |
Gestión de Estado Compartido | PROGRESO | PENDIENTE |
Control de Versiones | DEFINIDO | REALIZADA |
Seguridad | PROGRESO | PENDIENTE |
Gestión de Recursos | PENDIENTE | PENDIENTE |
Tema y Estilos Compartidos | DEFINIDO | REALIZADA |
Tolerancia a Fallos | PENDIENTE | PENDIENTE |
Monitorización y Registro | PENDIENTE | PENDIENTE |
Compatibilidad con Múltiples Frameworks | PROGRESO | PENDIENTE |
Vista general
Herramientas de contenido
- Impreso por Atlassian Confluence 8.7.2