Arquitectura

El modelo está escrito en LikeC4. LikeC4 fusiona todos los .c4 de un proyecto en un solo modelo, así que la división en archivos es solo para saber dónde editar: no impone restricciones sobre lo que se puede modelar.

arquitectura/
├── likec4.config.json     el proyecto: "digito"
├── especificacion.c4      kinds, tags y estilos. Se declaran una sola vez
├── landscape.c4           los sistemas y las relaciones sistema → sistema
├── sistemas/
│   ├── digito-api.c4      contenedores, con `extend digitoApi { ... }`
│   ├── digito-business.c4
│   ├── isi.c4
│   ├── mi-digito.c4
│   └── rse.c4
└── vistas.c4              las vistas, con ids explícitos

Visualizar

npm run dev:model     # http://localhost:5173, todas las vistas navegables

Doble clic en un sistema baja a sus contenedores. Al editar un .c4 el navegador se actualiza solo.

Para verlo junto al resto de la documentación, con búsqueda: npm run dev (ver ../sitio/).

Para validar sin levantar nada — es lo que debería correr en CI:

npm run check     # likec4 validate + likec4 fmt --check
npm run format    # arregla el formato

Dónde va cada cosa

Qué	Dónde
Un `softwareSystem` nuevo (interno o externo)	`landscape.c4`
Contenedores de un sistema	`sistemas/<sistema>.c4`, dentro de `extend`
Una relación	El archivo del sistema que origina la llamada
Una relación de la que no sabemos el contenedor origen	`landscape.c4`, con un `TODO`
Un kind, un tag o un estilo	`especificacion.c4`
Una vista	`vistas.c4`

Un sistema estrena archivo en sistemas/ cuando quieres modelarle contenedores. Los que no tienen (Nutrient, TSA, EJBCA, QCSD, …) viven solo como caja en el landscape, y eso está bien.

Las tres reglas

Cada relación se declara una sola vez, al nivel más preciso que se conozca. LikeC4 deriva sola la relación entre los sistemas padre para las vistas de alto nivel. Si declaras digitoBusiness -> digitoApi y también digitoBusiness -> digitoApi.digitoApiJS, salen las dos en los diagramas.
La declara el archivo del sistema que origina la llamada. Si no sabes de qué contenedor sale, déjala a nivel de sistema en landscape.c4 con un TODO, y bájala cuando se sepa. Esos TODO son la deuda visible del modelo.
Los ids de las vistas son la URL de la vista. Cambiarlos rompe los enlaces desde los ADRs y los boletines.

Los tags no son decoración

#interno / #externo son la frontera de confianza: qué operamos nosotros y qué opera un tercero. Es la distinción con peso regulatorio, y es lo que pinta los sistemas de gris en las vistas.
#firma-cualificada marca lo que participa en la generación de firmas cualificadas. De ahí sale la vista firma-cualificada, que es el subconjunto que le interesa a un supervisor. Cuando algo entra o sale de esa ruta, el tag se actualiza en el mismo PR.

Entregable para un tercero

npm run build:standalone    # entregable/index.html, autocontenido

Un solo HTML con todas las vistas, sin dependencias externas. Es lo que se le manda a alguien que no va a instalar nada, y lo que conviene adjuntar al boletín cuando la semana cambió la arquitectura.

Decisiones de arquitectura

No hay una bitácora aquí. Las decisiones de alcance organizacional están en ../decisiones/; las que caben dentro de un proyecto viven en el repositorio de ese proyecto.

Conviene enlazar cada sistema del modelo a su repositorio, para que la bitácora distribuida sea alcanzable desde el diagrama. LikeC4 lo soporta con link:

digitoApi = softwareSystem 'Digito API' {
  #interno
  link https://github.com/DigitoGroup/<repositorio> 'Repositorio'
  link https://github.com/DigitoGroup/<repositorio>/tree/main/decisiones 'Decisiones'
}

Está pendiente: falta confirmar el nombre del repositorio de cada sistema.

Archivos generados

Ninguno. Los .c4 son la fuente y no producen artefactos en el árbol; el layout lo calcula LikeC4 en cada corrida.