Versión: 1.0
Fecha: 29 de Diciembre, 2025
Estado: NORMATIVO - Proceso Obligatorio
Arquitecto: Carlos Alberto Torres Camargo
Este documento define el proceso específico del Arquitecto cuando recibe una solicitud de desarrollo que requiere un nuevo microservicio o componente arquitectónico significativo.
Aclaración: Este proceso es complementario al
PROCESO_OPERATIVO_FABRICA_SOFTWARE.md, que define el flujo operativo diario del equipo. Este documento se enfoca en actividades de arquitectura de alto nivel.
Este proceso se activa cuando:
NO aplica para:
FLUJO_DESARROLLO_NEBULA.md)Formato de Solicitud (JIRA o Email):
**Título:** [Solicitud Arquitectónica] Módulo de Nómina
**Solicitante:** Product Owner / Gerente Técnico
**Descripción:**
Requerimos implementar el módulo de nómina para Nebula ERP con las siguientes capacidades:
- Liquidación de nómina mensual, quincenal, semanal
- Cálculo de prestaciones sociales
- Integración con PILA (Planilla Integrada de Liquidación de Aportes)
- Generación de colillas de pago
- Reportes tributarios
**Alcance de Negocio:**
- Manejo de 50-500 empleados por cliente
- Cumplimiento normativo colombiano
- Integración con contabilidad (asientos automáticos)
**Restricciones:**
- Debe estar en producción en 16 semanas (Fase 3)
- Debe ser multi-tenant
- Debe soportar 3 motores SQL
**Prioridad:** ALTA
**Fecha Límite Decisión:** 2025-02-15
Checklist de Análisis:
¿Requiere nuevo microservicio?
nebula-payroll (dominio RRHH separado de contabilidad)¿Puede extender microservicio existente?
Bibliotecas compartidas requeridas:
CentricaModel: Nuevos DTOs (EmpleadoDto, NominaDto, ConceptoNominaDto)CentricaShared: Cliente HTTP para llamar a nebula-accountingServicios externos:
Investigación requerida:
| Tecnología | Propósito | Opciones | Decisión |
|---|---|---|---|
| Motor de reglas nómina | Cálculo flexible de conceptos | Drools, Easy Rules, código nativo | Easy Rules (simple, mantenible) |
| Integración PILA | Cumplimiento legal | API SOAP vs scraping | API SOAP (oficial) |
| Almacenamiento colillas | PDFs empleados | MinIO, DB, FileSystem | MinIO (S3-compatible) |
| Procesamiento async | Liquidación masiva | Kafka, Spring Batch | Spring Batch (mejor para nómina mensual) |
Resultado: ADR-010 (Architecture Decision Record)
Entidades Core (requieren ADR):
Empleado (maestro)
payroll.empleadocontabilidad.tercero (empleado es un tipo de tercero)Nomina (proceso)
payroll.nominaDetalleNomina (líneas)
payroll.detalle_nominaConceptoNomina (catálogo)
payroll.concepto_nominaMigraciones:
V1__create_payroll_schema.sqlV1__create_payroll_schema_oracle.sqlV1__create_payroll_schema_sqlserver.sqlDocumento: Architecture Decision Records (ADRs)
Ubicación: /Documentation/centrica/06_Arquitectura_Detallada/ADRs/
Archivos creados:
ADR-010_motor_reglas_nomina.mdADR-011_modelo_datos_payroll.mdADR-012_integracion_pila.mdADR-013_procesamiento_nomina_batch.mdTiempo estimado: 2-5 días (investigación + documentación)
Paso 1: Usar SimappeArchetype
# Ejecutado por el Arquitecto
cd /workspace/nebula-microservices/
mvn archetype:generate \
-DarchetypeGroupId=com.catcsoft.simappe \
-DarchetypeArtifactId=SimappeArchetype \
-DarchetypeVersion=2.0.0-SNAPSHOTS \
-DgroupId=com.centrica.nebula \
-DartifactId=nebula-payroll \
-Dversion=1.0.0-SNAPSHOT \
-Dpackage=com.centrica.nebula.payroll \
-DprojectName="Nebula Payroll Service" \
-DprojectDescription="Microservicio de gestión de nómina" \
-DenableMongo=true \
-DenableKafka=true \
-DenableMinio=true \
-DinteractiveMode=false
cd nebula-payroll
Paso 2: Configuración Base
# Actualizar application.yml
vim src/main/resources/application.yml
# Contenido:
spring:
application:
name: nebula-payroll
cloud:
config:
import: optional:configserver:http://simappe-config-server:8890
eureka:
client:
service-url:
defaultZone: http://simappe-eureka-server:8761/eureka/
# Multi-tenancy
datasource:
admin-url: http://simappe-admin:9010/simappe-admin/api/v1/admin/database-config/
Paso 3: Inicializar Repositorio Git
git init
git add .
git commit -m "chore: generar nebula-payroll con SimappeArchetype 2.0.0
- Estructura base con patrón Component
- Multi-tenancy habilitado
- MongoDB para auditoría
- Kafka para eventos
- MinIO para almacenamiento de colillas
Refs: ADR-011, NEB-250"
# Crear repositorio en GitLab/GitHub
git remote add origin git@github.com:centrica/nebula-payroll.git
git push -u origin main
# Crear rama develop
git checkout -b develop
git push -u origin develop
CentricaModel: Nuevos DTOs
cd /workspace/centrica-libraries/CentricaModel/
# Crear rama feature
git checkout -b feature/NEB-250-payroll-dtos
# Crear DTOs
mkdir -p src/main/java/com/centrica/nebula/model/payroll/
# EmpleadoDto.java, NominaDto.java, etc.
# (código completo omitido por brevedad)
# Commit
git add .
git commit -m "feat(payroll): agregar DTOs de nómina
- EmpleadoDto
- NominaDto
- DetalleNominaDto
- ConceptoNominaDto
Validaciones Jakarta Bean Validation incluidas.
Refs: NEB-250"
# Push y crear PR
git push origin feature/NEB-250-payroll-dtos
CentricaShared: Cliente HTTP
cd /workspace/centrica-libraries/CentricaShared/
git checkout -b feature/NEB-250-payroll-client
# Crear PayrollClient.java (Feign o WebClient)
# (código omitido)
git add .
git commit -m "feat(payroll): agregar cliente HTTP para nebula-payroll
- PayrollClient interface (WebClient HTTP Interface)
- Endpoints: /employees, /payrolls, /concepts
Refs: NEB-250"
git push origin feature/NEB-250-payroll-client
Jenkinsfile para nebula-payroll
pipeline {
agent any
tools {
maven 'Maven-3.9'
jdk 'JDK-25'
}
environment {
NEXUS_URL = 'http://nexus.internal:8081'
DOCKER_REGISTRY = 'registry.centrica.internal'
SONAR_URL = 'http://sonarqube.internal:9000'
}
stages {
stage('Build') {
steps {
sh 'mvn clean package -DskipTests'
}
}
stage('Test') {
steps {
sh 'mvn test'
junit 'target/surefire-reports/*.xml'
jacoco execPattern: 'target/jacoco.exec'
}
}
stage('SonarQube') {
steps {
withSonarQubeEnv('SonarQube') {
sh 'mvn sonar:sonar'
}
}
}
stage('Quality Gate') {
steps {
timeout(time: 5, unit: 'MINUTES') {
waitForQualityGate abortPipeline: true
}
}
}
stage('Docker Build') {
when {
branch 'develop'
}
steps {
sh '''
docker build -t ${DOCKER_REGISTRY}/nebula-payroll:${BUILD_NUMBER} .
docker tag ${DOCKER_REGISTRY}/nebula-payroll:${BUILD_NUMBER} ${DOCKER_REGISTRY}/nebula-payroll:latest
'''
}
}
stage('Deploy DEV') {
when {
branch 'develop'
}
steps {
sh '''
kubectl set image deployment/nebula-payroll \
nebula-payroll=${DOCKER_REGISTRY}/nebula-payroll:${BUILD_NUMBER} \
-n nebula-dev
'''
}
}
}
post {
always {
cleanWs()
}
failure {
emailext (
subject: "FAILED: Job '${env.JOB_NAME} [${env.BUILD_NUMBER}]'",
body: "Revisar en ${env.BUILD_URL}",
to: "arquitecto@centrica.com"
)
}
}
}
Guardar en:
# En repo nebula-payroll
vim Jenkinsfile
git add Jenkinsfile
git commit -m "ci: agregar pipeline Jenkins
- Build, Test, SonarQube, Docker
- Deploy automático a DEV en rama develop
- Quality Gate obligatorio
Refs: NEB-250"
Artefactos Generados:
nebula-payroll (repositorio Git)CentricaModel (PRs creados)CentricaShared (PR creado)V1__*.sql para 3 motores)Tiempo estimado: 1-2 días
El Arquitecto crea un "paquete de documentación" para el equipo de desarrollo:
Ubicación: /Documentation/centrica/07_Implementacion/Payroll/
README_PAYROLL.md# Nebula Payroll - Guía de Desarrollo
## Introducción
Microservicio de gestión de nómina para Nebula ERP.
## Arquitectura
- **Patrón:** Domain-Driven Design + CQRS
- **Base de Datos:** Multi-Motor SQL (PostgreSQL/Oracle/SQL Server)
- **Mensajería:** Kafka (evento `NominaLiquidada`)
- **Storage:** MinIO (colillas PDF)
- **Motor de Reglas:** Easy Rules
## Estructura de Paquetes
com.centrica.nebula.payroll
├── config/ # Configuración Spring
├── employee/ # Dominio Empleado
│ ├── entity/
│ ├── repository/
│ ├── component/
│ ├── service/
│ └── controller/
├── payroll/ # Dominio Nómina
│ ├── entity/
│ ├── component/
│ │ ├── PayrollCalculatorComponent.java # LÓGICA CRÍTICA
│ │ └── PayrollProcessorComponent.java
│ └── batch/ # Spring Batch jobs
└── concept/ # Dominio Conceptos
## Operaciones Clave
### Liquidar Nómina
**Endpoint:** `POST /api/v1/payroll/payrolls/{id}/process`
**Flujo:**
1. Validar periodo no liquidado previamente
2. Obtener empleados activos
3. Para cada empleado:
- Calcular devengados (aplicar reglas con Easy Rules)
- Calcular deducciones
- Calcular provisiones
- Crear detalle_nomina
4. Generar asiento contable (llamar a nebula-accounting)
5. Publicar evento Kafka `NominaLiquidada`
6. Generar colillas PDF (MinIO)
**Código de Referencia:**
Ver: `PayrollCalculatorComponent.java` (implementado por Arquitecto como referencia)
CONTRATOS_API.md# Contratos API - Nebula Payroll
## Endpoints Públicos
### 1. Crear Nómina
**Request:**
```http
POST /api/v1/payroll/payrolls/create
Content-Type: application/json
Authorization: Bearer {JWT}
{
"periodo": "2025-01",
"tipoNomina": "MENSUAL",
"fechaInicio": "2025-01-01",
"fechaFin": "2025-01-31",
"observaciones": "Nómina enero 2025"
}
```
Response:
{
"id": 123,
"periodo": "2025-01",
"estado": "BORRADOR",
"totalEmpleados": 0,
"totalDevengado": 0.0,
"totalDeducido": 0.0,
"totalNeto": 0.0,
"createdAt": "2025-01-01T10:00:00Z"
}
Request:
POST /api/v1/payroll/payrolls/123/process
Response:
{
"id": 123,
"estado": "LIQUIDADA",
"totalEmpleados": 50,
"totalDevengado": 150000000.0,
"totalDeducido": 25000000.0,
"totalNeto": 125000000.0,
"asientoContableId": 456,
"eventId": "evt-nomina-123"
}
Topic: payroll-events
Payload:
{
"eventType": "NOMINA_LIQUIDADA",
"nominaId": 123,
"periodo": "2025-01",
"totalNeto": 125000000.0,
"asientoContableId": 456,
"timestamp": "2025-01-31T18:00:00Z",
"tenantId": "client-abc"
}
Consumidores:
nebula-accounting: Registrar asiento contablenebula-treasury: Provisionar pago
#### Archivo 3: `TAREAS_DESARROLLO.md`
```markdown
# Plan de Desarrollo - Nebula Payroll
## Sprint 1 (Semanas 1-2): Fundamentos
### Backend Senior 1
- [ ] Implementar CRUD Empleado (NEB-251)
- [ ] Implementar CRUD ConceptoNomina (NEB-252)
- [ ] Migración Flyway V1 (3 motores)
### Backend Senior 2
- [ ] Configurar Easy Rules engine (NEB-253)
- [ ] Implementar reglas de cálculo básicas (NEB-254)
### Backend Junior 1
- [ ] Tests unitarios Empleado (NEB-255)
- [ ] Tests unitarios ConceptoNomina (NEB-256)
### QA
- [ ] Tests de integración CRUD (NEB-257)
## Sprint 2 (Semanas 3-4): Liquidación
### Backend Senior 1
- [ ] Implementar PayrollCalculatorComponent (NEB-260)
- [ ] Implementar Spring Batch job (NEB-261)
- [ ] Integración con nebula-accounting (NEB-262)
### Backend Senior 2
- [ ] Implementar generación PDF colillas (NEB-263)
- [ ] Integración con MinIO (NEB-264)
### QA
- [ ] Tests E2E liquidación completa (NEB-265)
## Sprint 3 (Semanas 5-6): Integración PILA
(Ver tickets NEB-270 a NEB-280)
## Estimación Total: 16 semanas (Fase 3)
Documentos Creados:
README_PAYROLL.md (guía técnica)CONTRATOS_API.md (endpoints y eventos)TAREAS_DESARROLLO.md (plan de sprints)Tiempo estimado: 1 día
Agenda (2 horas):
Presentación de arquitectura (30 min) [Arquitecto]
Demo del microservicio base (15 min) [Arquitecto]
Revisión de contratos API (30 min) [Arquitecto + Backend Senior]
Asignación de tareas (30 min) [Arquitecto]
Q&A (15 min)
Participantes:
Herramienta: OpenAPI 3.0 (generado con SpringDoc)
Paso 1: Backend genera contrato
# Ejecutar nebula-payroll localmente
mvn spring-boot:run
# Descargar OpenAPI spec
curl http://localhost:8080/v3/api-docs > payroll-api-openapi.json
Paso 2: Frontend genera cliente TypeScript
# Generar cliente Angular con openapi-generator
npx @openapitools/openapi-generator-cli generate \
-i payroll-api-openapi.json \
-g typescript-angular \
-o src/app/core/services/generated/payroll
Paso 3: Versionado del contrato
# Guardar en repositorio compartido
cd /workspace/centrica-contracts/
mkdir -p payroll/v1/
cp payroll-api-openapi.json payroll/v1/
git add .
git commit -m "docs: agregar contrato OpenAPI nebula-payroll v1.0"
git push
Email del Arquitecto:
Asunto: [Asignación] Implementación nebula-payroll
@backend-senior-1, @backend-senior-2
Les asigno la implementación de nebula-payroll conforme a la arquitectura aprobada.
**Repositorio:** https://github.com/centrica/nebula-payroll
**Documentación:** /Documentation/centrica/07_Implementacion/Payroll/
**ADRs:** /Documentation/centrica/06_Arquitectura_Detallada/ADRs/ADR-010 a ADR-013
**Contratos API:** /centrica-contracts/payroll/v1/payroll-api-openapi.json
**Plan:**
- Sprint 1: Fundamentos (Empleado, Conceptos)
- Sprint 2: Liquidación (Cálculo, Batch)
- Sprint 3: Integraciones (PILA, Contabilidad)
- Sprint 4-8: Features avanzadas
**Aprobaciones requeridas:**
- TODOS los PRs a CentricaModel/CentricaShared → Gatekeeper + Arquitecto
- TODAS las migraciones Flyway → Arquitecto
- Deploy a PROD → Arquitecto + QA Lead
**Primera tarea:**
Revisar documentación, ejecutar arquetipo localmente, crear ticket JIRA para Sprint 1.
**Reunión de seguimiento:** Viernes 10:00 AM (semanal)
Adelante.
/centrica-contractsTiempo estimado: 1 día
Frecuencia Semanal:
Code Review de PRs Críticos (2-3 horas/semana)
Aprobación de Migraciones (30 min/semana)
Reunión de Seguimiento (1 hora/semana)
Frecuencia por Sprint:
Sprint Review (2 horas/sprint)
Sprint Retrospective Técnica (1 hora/sprint)
Checklist del Arquitecto:
Aprobación formal:
✅ **APROBADO PARA PRODUCCIÓN**
**Feature:** Liquidación de nómina (NEB-260 a NEB-265)
**Versión:** v1.2.0
**Sprint:** 3.2
**Validaciones:**
- ✅ Funciona correctamente en QA (10 nóminas liquidadas)
- ✅ Performance P95: 380ms (meta: <500ms)
- ✅ Multi-tenancy OK (3 tenants probados)
- ✅ Migraciones Flyway: V3\_\_payroll_batch.sql (OK en QA)
- ✅ SonarQube: 0 bugs, 0 vulnerabilidades
- ✅ Cobertura: 87%
**Autorización:** Deploy a PROD autorizado para ventana del viernes 31/01/2025 22:00 UTC-5.
**Monitoreo post-deploy:** 48 horas intensivo.
@devops adelante con deploy.
| Tu Propuesta Original | Proceso Refinado | Comentario |
|---|---|---|
| Solicitud de desarrollo | ✅ Solicitud formal (JIRA o Email) | OK - Formalizar template |
| Arquitecto analiza | ✅ Fase 1: Análisis Arquitectónico | OK - Agregar investigación de tecnologías |
| Genera artefactos | ✅ Fase 2: Generación de Artefactos | OK - Incluir bibliotecas compartidas |
| Definición del modelo de datos | ✅ Incluido en Fase 1 (ADRs) | OK - Usar Architecture Decision Records |
| Evalúa tecnologías puntuales | ✅ Incluido en Fase 1 (Investigación) | OK - Documentar en ADRs |
| Usa arquetipo | ✅ Fase 2.1: Generar con SimappeArchetype | OK - Automatizado |
| Genera repo | ✅ Fase 2.3: Inicializar Git | OK - Incluir Jenkinsfile |
| Genera documentación | ✅ Fase 3: Documentation Pack | MEJORADO - 3 documentos clave |
| Reunión backend/front | ✅ Fase 4.1: Reunión de Kick-off | OK - Agenda formal |
| Establece contratos APIs | ✅ Fase 4.2: Contratos OpenAPI | MEJORADO - Generar cliente TS |
| Activa desarrollo | ✅ Fase 4.3: Asignar a Backend Senior | OK - Email formal |
| ❌ (faltaba) | ✅ Fase 5: Supervisión Continua | NUEVO - Code reviews, aprobaciones |
Conclusión: Tu propuesta era 90% correcta. Los gaps principales eran:
| Fase | Duración | Acumulado |
|---|---|---|
| Fase 1: Análisis | 2-5 días | 5 días |
| Fase 2: Generación | 1-2 días | 7 días |
| Fase 3: Documentación | 1 día | 8 días |
| Fase 4: Entrega | 1 día | 9 días |
| Fase 5: Supervisión | Continua (2-3 h/semana) | - |
Total: 8-9 días laborales para entregar un microservicio listo para desarrollo.
✅ Generación de microservicio: mvn archetype:generate (SimappeArchetype)
✅ Generación de cliente TypeScript: openapi-generator-cli
✅ Build/Test/Deploy: Jenkins CI/CD
✅ SonarQube Quality Gate: Automático en pipeline
✅ Migraciones DB: Flyway (automático en startup)
Herramienta: Herramientas de generacion de codigo
# Generar README.md a partir de template
generate-docs \
--template=microservice-readme \
--service=nebula-payroll \
--output=README_PAYROLL.md
Ahorro: 50% del tiempo de Fase 3
Herramienta: ADR Tools
# Generar ADR a partir de conversación
adr-gen \
--decision="Usar Easy Rules para motor de reglas nómina" \
--context="Requerimos flexibilidad en cálculo de conceptos" \
--alternatives="Drools,código nativo" \
--output=ADR-010_motor_reglas_nomina.md
Ahorro: 30% del tiempo de Fase 1
Herramienta: Lattix (análisis de dependencias) + SonarQube
# Detectar si nueva feature requiere nuevo microservicio
lattix-cli analyze-impact \
--feature="Gestión de Nómina" \
--existing-services=nebula-accounting,nebula-billing \
--recommendation
Output:
✅ Recommendation: CREATE NEW MICROSERVICE
Reasons:
- Domain isolation: Payroll is independent from Accounting
- Team structure: Dedicated RRHH team available
- Scalability: Different load patterns (monthly batch vs. daily transactions)
Confidence: 87%
Ahorro: 20% del tiempo de Fase 1
Herramienta: Herramientas de generacion de tests
# Generar tests unitarios a partir de código
diffblue cover \
--source=src/main/java/com/centrica/nebula/payroll/component/PayrollCalculatorComponent.java \
--output=src/test/java/
Ahorro: 40% del tiempo de desarrollo (no del arquitecto)
❌ Decisiones arquitectónicas críticas (nuevo microservicio vs. extender existente)
❌ Evaluación de alternativas tecnológicas (requiere experiencia y contexto de negocio)
❌ Aprobación de migraciones de BD en producción (riesgo de data loss)
❌ Definición de modelo de datos core (impacto en toda la aplicación)
❌ Code review de lógica de negocio compleja (requiere comprensión de dominio)
❌ Aprobación de deploy a producción (responsabilidad legal/financiera)
Tendencia: Crear "Internal Developer Platform" (IDP)
Herramientas:
Implementación para Centrica:
# backstage-catalog.yaml
apiVersion: backstage.io/v1alpha1
kind: Component
metadata:
name: nebula-payroll
description: Microservicio de gestión de nómina
tags:
- java
- spring-boot
- payroll
links:
- url: https://github.com/centrica/nebula-payroll
title: Repositorio
- url: http://jenkins.internal/job/nebula-payroll
title: Pipeline CI/CD
- url: http://swagger.internal/payroll
title: API Docs
spec:
type: service
lifecycle: production
owner: team-payroll
system: nebula-erp
dependsOn:
- component:nebula-accounting
- resource:kafka-cluster
- resource:postgres-payroll
Beneficio: Developers pueden descubrir y entender servicios sin preguntar al arquitecto.
Tendencia: "Infrastructure as Code" versionado en Git
Herramientas:
Implementación para Centrica:
# argocd-application.yaml
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
name: nebula-payroll
spec:
project: nebula-erp
source:
repoURL: https://github.com/centrica/nebula-k8s-manifests
targetRevision: main
path: payroll/
destination:
server: https://kubernetes.default.svc
namespace: nebula-prod
syncPolicy:
automated:
prune: true
selfHeal: true
Beneficio: Arquitecto aprueba cambios en Git, ArgoCD deploya automáticamente.
Tendencia: Definir arquitectura en código ejecutable
Herramientas:
Implementación para Centrica:
// ArchitectureTest.java
@AnalyzeClasses(packages = "com.centrica.nebula.payroll")
public class ArchitectureTest {
@ArchTest
static final ArchRule components_should_use_connection_context =
classes()
.that().resideInAPackage("..component..")
.should().beAnnotatedWith(ConnectionContext.class);
@ArchTest
static final ArchRule controllers_should_not_access_repositories =
noClasses()
.that().resideInAPackage("..controller..")
.should().accessClassesThat().resideInAPackage("..repository..");
@ArchTest
static final ArchRule services_should_not_have_business_logic =
classes()
.that().resideInAPackage("..service..")
.should().onlyHaveDependentClassesThat()
.resideInAnyPackage("..component..", "..service..");
}
Beneficio: Validación automática de cumplimiento de patrones arquitectónicos.
Tendencia: Arquitectos consideran costos desde el diseño
Herramientas:
Implementación para Centrica:
# Estimar costo de nuevo microservicio
infracost breakdown \
--path=terraform/nebula-payroll/ \
--format=table
# Output:
Project: nebula-payroll
├─ Pod CPU requests (2 cores): $50/month
├─ Pod Memory requests (4 GB): $20/month
├─ PostgreSQL DB (50 GB): $100/month
├─ Redis Cache (2 GB): $30/month
├─ Load Balancer: $25/month
└─ Data Transfer (500 GB): $45/month
TOTAL: $270/month
Beneficio: Arquitecto puede justificar o rechazar nuevo microservicio por costo.
✅ Tu proceso propuesto es CORRECTO en su esencia.
✅ Faltaban formalizaciones (ADRs, contratos OpenAPI, supervisión continua).
✅ Con los refinamientos de este documento, tienes un proceso de nivel enterprise.
Estás en el rol correcto. Tus responsabilidades son:
✅ Diseñar arquitectura (no implementar todo el código operativo)
✅ Generar artefactos base (arquetipo, bibliotecas, ADRs)
✅ Documentar y capacitar al equipo
✅ Supervisar calidad arquitectónica (code reviews críticos, aprobaciones)
✅ Aprobar deploys a producción
❌ NO debes: Implementar todas las features, provisionar infraestructura física, gestión administrativa del equipo.
Con 15+ años de experiencia, estás más que calificado para este rol. Este proceso te ayudará a operacionalizarlo efectivamente.
Para cada solicitud de desarrollo que requiera nuevo microservicio:
FASE 1: ANÁLISIS (2-5 días)
[ ] Evaluar si requiere nuevo microservicio
[ ] Investigar tecnologías puntuales
[ ] Diseñar modelo de datos core
[ ] Crear ADRs (4-5 documentos)
FASE 2: GENERACIÓN (1-2 días)
[ ] Generar microservicio con SimappeArchetype
[ ] Crear DTOs en CentricaModel (PR)
[ ] Crear cliente HTTP en CentricaShared (PR)
[ ] Configurar Jenkinsfile
[ ] Crear migraciones Flyway (3 motores)
FASE 3: DOCUMENTACIÓN (1 día)
[ ] Crear README técnico
[ ] Crear CONTRATOS_API (OpenAPI)
[ ] Crear TAREAS_DESARROLLO (plan de sprints)
FASE 4: ENTREGA (1 día)
[ ] Reunión de kick-off (2 horas)
[ ] Publicar contratos OpenAPI
[ ] Asignar a Backend Senior
[ ] Generar cliente TypeScript para frontend
FASE 5: SUPERVISIÓN (continua)
[ ] Code reviews semanales (2-3 h/semana)
[ ] Aprobación de migraciones
[ ] Reunión de seguimiento semanal
[ ] Aprobación de deploy a PROD
Fin del Documento
Próxima Actualización: Tras implementación del primer microservicio con este proceso (nebula-payroll recomendado como piloto).
| Version | Fecha | Autor | Descripcion |
|---|---|---|---|
| 1.1.0 | 2026-03-04 | Carlos Torres | Revision, sanitizacion y publicacion en Wiki Arquitectura Centrica. |
| 1.0.0 | 2025-12-29 | Carlos Torres | Creacion del documento. |