Saltar al contenido principal

CASO DE ESTUDIO · FINANZAS DEL HOGAR

Yukidoke

Un producto privado de finanzas personales para hogares, construido con Angular 22 y una API modular en .NET 10. Está pensado para manejar finanzas compartidas sin hacer visibles por defecto todos los registros de cada miembro.

Código privado Activo

PROBLEMA

El dinero compartido del hogar todavía contiene información privada

Un producto de finanzas familiares debe representar obligaciones realmente compartidas sin convertir por defecto los registros financieros privados de cada miembro en datos visibles para todo el hogar. Tarjetas, deudas, ingresos, presupuestos y recomendaciones también necesitan una única ruta de cálculo autoritativa, no fórmulas ligeramente distintas en cada cliente.

Por eso Yukidoke trata autenticación, membresía del hogar y visibilidad por registro financiero como límites independientes, no como una sola verificación de “usuario autenticado”.

SISTEMA

La presentación está separada de la autoridad financiera

Límite del sistema Yukidoke V1. Angular controla la interacción y el estado transitorio del cliente. Keycloak establece la identidad. La API .NET 10 controla la autorización por hogar y las reglas financieras, mientras PostgreSQL mantiene el estado duradero. Worker y Database Migrator comparten el código del monolito modular.

ARQUITECTURA

Un monolito modular mantiene comprensibles las transacciones de V1

LÍMITE 01

KEYCLOAK CONTROLA LA IDENTIDAD

El navegador es un cliente OIDC público que usa Authorization Code + PKCE. La identidad global se mantiene deliberadamente separada de la membresía del hogar y de los permisos financieros.

LÍMITE 02

LA API CONTROLA LAS REGLAS FINANCIERAS

El cliente Angular expresa intención y renderiza estado. Los permisos por hogar, el comportamiento contable, los cálculos de salud financiera y los modelos de lectura persistentes pertenecen a la API en lugar de duplicarse en el navegador.

LÍMITE 03

POSTGRESQL CONTROLA EL ESTADO PERSISTENTE

Los módulos persisten mediante PostgreSQL con migraciones EF Core y concurrencia optimista. Database Migrator aplica las migraciones de forma explícita en lugar de permitir que cada proceso cambie el esquema al iniciar.

FLUJO DE DATOS

REST recupera la verdad; SignalR añade cambios incrementales

El cliente Angular usa clientes REST tipados, normalización de paginación y manejo de ProblemDetails. El estado de notificaciones se carga desde REST y SignalR añade actualizaciones incrementales, de modo que una reconexión no cambia de dónde proviene el estado persistente.

Esta diferencia importa en finanzas: un evento por WebSocket puede mejorar la respuesta de la interfaz, pero no debería ser el único registro de que existe un balance, una notificación o una acción del hogar.

IMPLEMENTACIÓN ACTUAL

Qué incluye hoy la beta V1

WEB

ANGULAR 22 · 0.9.0-RC.1

El cliente web usa Angular 22 e identifica la versión 0.9.0-rc.1. Incluye contexto y guards de capacidades por hogar, clientes API tipados, flujos de deudas, tarjetas y payoff, ingresos, consolidación de Planning, invitaciones y administración del hogar, localización EN/ES y un harness de navegador contra el stack real de soporte.

API

MONOLITO MODULAR .NET 10

La API usa .NET 10 y organiza Users, Households, Accounting, Cards, Debts, Incomes, Planning, Notifications y Overview como módulos. Usa PostgreSQL 16, autenticación con Keycloak y procesos Worker y Database Migrator, con integración contra servicios reales de PostgreSQL y Keycloak.

PRIVACIDAD

La existencia de un recurso forma parte del modelo de autorización

Los endpoints con alcance por hogar pueden ocultar un recurso a quien no pertenece al hogar en lugar de revelar que existe y responder después con “forbidden”. Así, la existencia del recurso también queda dentro del límite de privacidad.

La beta todavía está en trabajo alrededor de privacidad, exportaciones, balances, autenticación y aceptación sobre un stack limpio antes de que considere adecuado usar datos financieros reales del hogar.

LÍMITE ACTUAL

V1 sigue en beta privada

ESTADO DEL PRODUCTO

BETA PRIVADA · DESARROLLO ACTIVO

El código sigue siendo privado. El trabajo actual se concentra en autorización, consistencia financiera, persistencia, exportaciones, privacidad y aceptación sobre un stack limpio antes de incluir datos financieros reales del hogar.

APRENDIZAJES

Lo que aprendí trabajando el límite por hogar

APRENDIZAJE 01

AUTENTICACIÓN NO ES AUTORIZACIÓN

Identidad, membresía del hogar y visibilidad de un registro financiero específico necesitan reglas y pruebas independientes.

APRENDIZAJE 02

SIGNALR NO DEBE SER LA FUENTE DE DURABILIDAD

SignalR es útil para actualizaciones incrementales; el estado recuperable por REST sigue siendo la autoridad cuando una conexión se pierde o reconecta.

APRENDIZAJE 03

UN MONOLITO MODULAR PUEDE SER UNA DECISIÓN DELIBERADA

Los límites de dominio, la responsabilidad sobre migraciones y la consistencia transaccional pueden ser explícitos sin asumir el costo operativo de servicios distribuidos antes de que V1 los necesite.