When building backend services, it is very easy to start with the framework. Create the controller. Generate the database entity. Add the repository. Then somewhere between HTTP requests and database tables, try to find a place where the business logic fits. I have built many systems this way. It works. Until it doesn’t. Over time I have started moving in the opposite direction: Start with the domain. Everything else is just an adapter. ...
A practical introduction to Railway-Oriented Programming in Kotlin using Arrow’s Either. Learn how to replace exception-driven business logic with explicit, composable error handling.
One of the principles that has shaped how I write software over the years is that code should explain itself.
Why I chose http4k over Spring Boot for my latest Kotlin project, and the trade-offs I considered.
Abstractions make software easier to change, but they also make it harder to understand. The challenge is knowing when they’re worth the cost.
One of the principles that has shaped how I write software over the years is that code should explain itself.
Functional programming didn’t change the language I use. It changed the way I think about designing software.
I used to create a repository interface for every aggregate. Over time I found a simpler approach that makes dependencies more explicit and business use cases easier to understand.