accounts
Producto de cuentas financieras. El dominio que guarda y protege la lógica de negocio.
Architecture / field notes
Products that
travel well.
Una arquitectura de microservicios donde un producto de cuentas puede llegar a muchos canales, sin perder la propiedad de sus reglas.
PocAccounts09 chaptersSecurity by design
01 / Proposito
Una idea simple,
muchos puntos de entrada.
Este proyecto es un boceto para representar cómo una organización puede construir productos independientes como microservicios y exponerlos a distintos canales de consumo.
portalnet
Canal operativo que permite administrar cuentas y transacciones.
sitecorp
Canal informativo que consulta cuentas, saldos y movimientos, y ejecuta simulaciones únicamente en el cliente.
Los canales no contienen la lógica principal del producto. Consumen las APIs de los microservicios y presentan la información de acuerdo con las necesidades de cada experiencia.
02 / Componentes
Cada pieza conoce
su trabajo.
SERVICE 01
Auth
auth es un microservicio externo de autenticación. Tiene sus propias entidades, persistencia y reglas internas para:
- • Registrar usuarios.
- • Validar credenciales.
- • Generar y almacenar tokens.
- • Resolver el usuario asociado a un token mediante
GET /me.
El endpoint
/me recibe un encabezado Authorization: Bearer <token> y retorna la identidad necesaria para que otros servicios conozcan quién realiza la petición. Auth no necesita conocer las reglas específicas de cuentas, transacciones o cualquier otro producto. Su responsabilidad es autenticar y entregar una identidad confiable.SERVICE 02
Accounts
accounts es un microservicio de producto. Contiene la lógica de negocio relacionada con:
- • Cuentas.
- • Transacciones asociadas a una cuenta.
- • Reglas de propiedad y acceso a los recursos.
Antes de ejecutar los métodos de cuentas, su middleware extrae el Bearer token y consulta el endpoint /me de auth. La respuesta se agrega al request como req.user. A partir de ese momento, accounts aplica su autorización internamente, verificando que la cuenta pertenezca al providerId del usuario autenticado. Esta decisión se toma dentro del servicio y no dentro de ningún canal.
Portalnet
Canal de administración que consume accounts para crear, consultar, actualizar y eliminar cuentas; y crear, consultar y actualizar transacciones. Envía el token recibido durante el login en cada petición protegida. No decide si una cuenta pertenece al usuario: esa validación corresponde a accounts.
Sitecorp
Canal de consulta que consume accounts para consultar cuentas y transacciones, calcular saldos y métricas para presentación, y ejecutar simulaciones locales de intereses y proyecciones. Las proyecciones son informativas, se calculan en el navegador y no crean ni modifican datos en accounts.
03 / Flujo de una petición protegida
A credential moves.
Ownership stays home.
UsuarioPortalnet
o SitecorpAccountsAuthPersistencia
Accounts
o SitecorpAccountsAuthPersistencia
Accounts
Inicia sesión
POST /login
→ Token
→ Token
Solicita recurso
Petición con
Bearer token
Bearer token
GET /me
con token
con token
Identidad +
providerId
providerId
Consulta o
modificación
modificación
↑→→→→
Presentación
Respuesta del producto
Autoriza según reglas internas
Resultado
El token funciona como credencial de transporte. La autorización de los recursos no se delega al canal: accounts consulta la identidad y determina internamente qué puede hacer ese usuario.
04 / Identidad y autorización
The ID tells you who.
The providerId tells you whose.
id
Identificador interno
Identificador de un usuario dentro del servicio auth.
providerId
Identidad de origen
Identificador del usuario en el proveedor de identidad o sistema externo que originó esa identidad.
Autorización agnóstica al canal
El servicio accounts utiliza el providerId como referencia de propiedad de sus cuentas. Tanto portalnet como sitecorp, una aplicación móvil o un futuro canal de terceros deben enviar la misma identidad autenticada; la regla de acceso siempre se aplica en accounts.
Este enfoque evita que un canal pueda decidir o falsificar el propietario de un recurso. El cliente no debe enviar un providerId confiable en el body para crear o consultar una cuenta. El servicio lo obtiene del usuario autenticado y lo aplica internamente.
05 / Estado actual del boceto
A monorepo
for the idea.
Para facilitar la demostración, actualmente los servicios viven dentro de un mismo monorepo:
apps/ auth/ accounts/ portalnet/ sitecorp/
Una DB, dos fronteras visibles
También se utiliza la misma base de datos física para el ejemplo. Cada servicio utiliza un prefijo diferente en sus tablas:
auth_tablas de authaccounts_tablas de accountsEsto permite ejecutar el boceto con una infraestructura pequeña y observar las relaciones entre los componentes, pero no debe interpretarse como el diseño final de una plataforma de microservicios.
06 / Evolución hacia microservicios reales
One domain.
One home for its data.
{{ item }}
En ese escenario, auth no compartiría tablas con accounts. Accounts solo conocería el contrato de identidad expuesto por Auth y mantendría sus propias cuentas y transacciones en una base de datos independiente. El prefijo de tablas usado en este repositorio es únicamente una aproximación didáctica para simular separación dentro de una misma base de datos.
07 / Seguridad
Centralize the trust.
Distribute the responsibility.
Auth como punto especializado
- • Las credenciales y la emisión de tokens se gestionan en un único punto especializado.
- • Los productos no necesitan duplicar lógica de login, registro o validación de credenciales.
- • Las políticas de autenticación pueden evolucionar de forma centralizada.
- • Los canales no necesitan conocer ni almacenar reglas internas de otros productos.
- • Se reduce la probabilidad de que cada aplicación implemente la autenticación de una manera diferente.
- • La autorización de cuentas permanece cerca de los datos y del dominio que debe protegerlos.
La separación importa
La centralización no significa que Auth deba decidir todos los permisos. Auth autentica y entrega la identidad; accounts autoriza sus propios recursos usando esa identidad. Esta separación mantiene responsabilidades claras y evita acoplar las reglas de cuentas a un canal.
Medidas adicionales para producción
• Tokens con expiración y renovación controlada.• Hash seguro de contraseñas.• TLS entre canales y servicios.• Validación estricta de entradas.• Rate limiting y protección contra abuso.• Auditoría de accesos y cambios.• Gestión segura de secretos.• Políticas de CORS restringidas por entorno.• Revisión de permisos y pruebas de aislamiento entre usuarios.
08 / Escalabilidad
Let demand decide
what grows.
Escala por demanda
- • Auth puede escalar de forma independiente si aumenta el número de logins o validaciones de identidad.
- • Accounts puede escalar según el volumen de consultas y operaciones financieras.
- • Portalnet y Sitecorp pueden desplegarse y versionarse sin publicar cambios en los servicios de backend.
Autonomía de producto
- • Un canal con necesidades especiales no obliga a modificar la experiencia de los demás canales.
- • Los equipos pueden evolucionar productos distintos con contratos de API claros.
- • La base de datos independiente evita que una migración o carga elevada afecte directamente a la persistencia de otro producto.
- • El aislamiento de datos, despliegue e infraestructura permite elegir estrategias de almacenamiento y escalado adecuadas para cada dominio.
09 / Idea central
Channels consume.
Products protect.
Canal de consumo
→
API del producto (accounts)
Base de datos propia del producto
↓
Servicio de identidad (auth)
Identidad autenticada
Los canales consumen productos. Los productos protegen sus propios recursos. Auth centraliza la autenticación. Cada microservicio conserva la responsabilidad de autorizar sus datos utilizando únicamente la identidad confiable proporcionada por el sistema de autenticación.
PocAccounts / end of field notes