The domain model comes first
Real business rules live in a model that names them, behind an API with clear contracts and validation at the edge. Frameworks and databases plug in around it.
Seen in: Sall Whisky Distillery →
~/what-i-do/backend
Most of a product lives in its backend: the APIs, the data and the services behind them. I build those around the domain, so the business rules are easy to find, the data can be trusted and a slow dependency never takes the product down.
Real business rules live in a model that names them, behind an API with clear contracts and validation at the edge. Frameworks and databases plug in around it.
Seen in: Sall Whisky Distillery →
An ORM is a tool, not a hiding place. I design the schema, write SQL where it matters and use what Postgres already does, from full-text to vector search, before adding another service.
Seen in: Jobbuddy →
Slow or unreliable work goes on a queue, with retries and backoff, idempotency and an audit trail, so a flaky dependency never takes the product down.
Seen in: Illux Product AI →
Providers, databases and AI models sit behind ports and adapters, so changing vendor is a new adapter, not a rewrite.
Seen in: Jobbuddy →
Generative-AI product enrichment & room visualization for Shopware 6
AI job-application platform - from posting to tailored CV
A bilingual technical dictionary you can explore as a map
One React codebase, running on the web and as an LG webOS TV app
Spin a wheel, settle movie night
GitHub activity turned into an evidence-based portfolio
One production domain, built twice - JavaFX and Spring Boot + Angular
Log bird sightings where you stand; see everyone's on a map
A JavaFX desktop app with real business rules
One business core, two frontends - WPF and ASP.NET MVC
Booking and management for a real riding school
Multiplayer Yahtzee with server-authoritative scoring
Real-time multiplayer over raw TCP sockets
A textbook n-tier .NET solution with three clients
No posts on this yet. Coming soon.