Skip to main content
> <sandovaldavid/>
[ BACK TO PROJECTS ]
BOSS FIGHT // CASE STUDY

Yukidoke

A household-scoped personal-finance platform built with Angular 22 and a .NET 10 modular monolith. The current V1 beta focuses on privacy-aware household finance, a double-entry ledger and API-owned business rules.

Angular TypeScript RxJS C# / .NET PostgreSQL
Yukidoke household-finance platform architecture preview
LIFECYCLE
Active — V1 beta in progress
SOURCE ACCESS
Private repositories; source is not publicly inspectable.
DEMO ACCESS
No public demo; production readiness for real household data is not claimed.
LIMITATIONS
  • Both source repositories are private, so public reviewers cannot inspect commits, tests or ADRs directly.
  • No adoption, revenue or production-scale claim is made for this project.

CURRENT STATUS

V1 beta — active architecture migration

Implemented capabilities and remaining work are reported separately. Production readiness for real household financial data is not claimed.

THE BOSS // PROBLEM

Household finances combine shared obligations with private information. The product needed to model cards, debts and income for several family members without exposing one member's private records or duplicating financial calculations across clients.

THE STRATEGY // APPROACH

I separated presentation from financial authority: an Angular 22 SPA owns interaction and feature-local state, while an ASP.NET Core .NET 10 modular monolith owns household permissions, accounting rules and durable read models. PostgreSQL stores module data, Keycloak issues identity, and REST remains authoritative when realtime delivery is unavailable.

THE SACRIFICE // TRADE-OFFS

I chose a modular monolith and one PostgreSQL database instead of distributed services to keep V1 transactions, migrations and local operations understandable. The repositories and deployment remain private while the household model and remaining verticals mature, so this portfolio documents reproducible architecture evidence rather than claiming a public production launch.

VICTORY // OUTCOME

The V1 foundation now demonstrates the advertised Angular/.NET stack with household scoping, a shared ledger engine, cards, debts, income, typed API clients, optimistic concurrency and recoverable notification state. Planning, complete notifications, real-stack cutover and public deployment remain explicitly tracked as future work.

IMPLEMENTED // VERIFIED IN REPOSITORY DOCUMENTATION

  • Angular 22 standalone SPA with lazy routes, household context, capability guards and feature-local signal stores.
  • Keycloak Authorization Code + PKCE integration, guarded bearer-token attachment and loopback-only development mock authentication.
  • .NET 10 ASP.NET Core Minimal API modular monolith with Users, Households, Accounting, Cards, Debts and Incomes modules plus a development OpenAPI document.
  • PostgreSQL 16 schema-per-module persistence, EF Core migrations, optimistic concurrency and a double-entry ledger engine.
  • Typed REST clients, ProblemDetails presentation, pagination normalization and SignalR notification reconciliation.
  • Unit, integration, functional, browser and accessibility test infrastructure documented across the two repositories.

PLANNED // NOT PRESENTED AS SHIPPED

  • Move every remaining legacy financial calculation and recommendation behind API-authoritative contracts.
  • Rework Planning capabilities for budgets, goals, subscriptions and asset tracking on the current household model.
  • Complete durable notification templates, localization, action routing and backend delivery guarantees.
  • Finish real-stack financial contract tests, internationalization enforcement and production-readiness verification.
  • Publish a recruiter-accessible repository or reproducible public demo after privacy and cutover criteria are verified.

ARCHITECTURE // CURRENT IMPLEMENTATION

Angular 22 SPA

Routes · signal stores · typed REST clients

.NET 10 Minimal API

Household scope · rules · ProblemDetails

Keycloak

OIDC · Authorization Code + PKCE

Users · Households · Accounting

Cards · Debts · Incomes

PostgreSQL 16

Schema per module · EF Core migrations

Worker + Database Migrator

Background shell · migration authority

Current V1 shape: Angular is the interaction layer; Keycloak issues identity; the .NET API owns household authorization and financial rules; PostgreSQL is the durable system of record. Worker and migrator are separate processes in the same modular-monolith codebase.

SECURITY DECISIONS

  • The browser is a public OIDC client and contains no client secret; login uses Authorization Code + PKCE.
  • Keycloak owns identity and global roles, while the API and PostgreSQL own household membership, permissions and per-record visibility.
  • Household-scoped routes conceal resource existence from non-members and use optimistic concurrency for conflicting writes.
  • Production readiness remains blocked until privacy enforcement and real-stack authorization coverage are verified end to end.

TESTING DECISIONS

  • Angular uses colocated Vitest specs plus Playwright and Axe journeys for browser behavior and accessibility.
  • The API uses xUnit and NSubstitute for domain/application tests, with Testcontainers for real PostgreSQL and Keycloak integration paths.
  • Repository documentation records local quality commands, but disabled or skipped GitHub Actions are not reported as passing evidence.
  • Complete frontend-to-real-API financial contract coverage is still planned and is not counted as implemented.

DEPLOYMENT DECISIONS

  • The API development stack is reproducible with Docker Compose for PostgreSQL, Keycloak, the migrator, API and worker.
  • The frontend has development, staging and production endpoint configuration, while local development can use json-server or the .NET API.
  • The migrator is the only process allowed to apply EF Core migrations; the API and worker remain stateless application processes.
  • A public production deployment is intentionally not linked because operational and privacy verification is incomplete.
DURATION

Active V1 beta

ROLE

Product and full-stack engineer

XP GAINED // KEY LEARNINGS

  • Keep authentication, household authorization and per-record financial visibility as separate boundaries.
  • Use REST-recovered durable state as the source of truth and treat SignalR as an incremental optimization.
  • A modular monolith can preserve domain boundaries and transactional consistency without premature distributed infrastructure.

ACCESS AND EVIDENCE LIMITATIONS

  • Both source repositories are currently private, so public reviewers cannot inspect commits, tests or ADRs directly.
  • No recruiter-accessible live demo is presented as production-ready.
  • The architecture diagram summarizes the documented current implementation; planned modules are listed separately.
  • Outcomes are qualitative and repository-backed; no adoption, revenue, performance or coverage percentage is claimed here.

SOURCE REPOSITORIES