01 / 06
Users and business first.
Start from what users are trying to achieve and why, then choose the technology. Product and engineering are one discipline, not two.
I’m an all-over-the-stack software engineer and a builder at Duna. I maintain open-source tools a lot of apps run on, and I write about the design of the systems we build.
01 / 06
Start from what users are trying to achieve and why, then choose the technology. Product and engineering are one discipline, not two.
02 / 06
Set clear expectations and assume people will do the right thing. From there, their actions grow or shrink that trust. Trust arrives on foot and leaves on horseback.
03 / 06
When people share the goals, the context and the constraints, they can make good decisions on their own. How to get there is up to the people doing the work.
04 / 06
If you get the freedom to decide or build, you own the outcome. That includes the maintenance and the cleanup. Your autonomy ends where it starts imposing on others.
05 / 06
A leader sets clear goals, shares context, makes the hard calls and gives cover to the people doing the work. Good leaders adapt to the people they lead, not the other way around.
06 / 06
Everyone has something to teach and something to learn. Learning is a mindset, not a phase you grow out of, whatever your seniority.
Notes on software design, architecture, domain-driven design and distributed systems.

1 min read
Over the last couple of years, this blog has gone stale. I intend to change that and produce more content when I learn something new. This new content will still cover a lot of the things you're used to: software design, architecture, domain-driven design, and distributed…
In my ever-lasting battle against anemic domain models I've developed a preference on how to integrate with the external concerns. In this post I'd like to show an alternative, a strategy on how to keep encapsulating behaviour wile interacting with the outside world.
4 min readSoftware Design
Event-driven architectures have various styles of communication. In my previous post I described a couple of event types you may see in these kinds of architectures.
7 min readEvent-Driven Architectureevent sourcing
Event-driven systems come in all sorts of shapes and sizes. The obvious commonality is; they all use events to communicate information. These events come in many shapes and sizes, and determining what goes into an event has an immense impact on the design of your system.
6 min readSoftware DesignEvent-Driven Architecture
Using events in a system is great, but how do you know for sure if you've reliably dispatched your events? The transportation of events needs to be done reliably while maintaining overall system consistency, be it eventual or immediately.
6 min read
Tools I maintain for the work we do as developers.
Since 2013, PHP
Since 2018, PHP
Since 2023, TypeScript
Hi, I’m Frank.
At Duna we help regulated companies onboard new customers safely, faster, and with higher conversion. We’re changing how companies stay compliant.
2023 to now
Proposed going policy-first and took it from design to delivery: the Policy Engine now powers our onboarding suite and case review. Built the shared tooling we ship on, including an event-sourcing toolkit for high-consistency domains.
2022 to 2023
Set the technical direction that unblocked several P0 priorities, built proofs of concept to test the risky parts, and aligned seven engineering teams behind the plan.
2019 to 2022
Drove Mollie’s EventSystem from first design to long-term tooling and moved the whole organisation onto transactional outboxes. Wrote the plan for leaving the monolith, introduced a technology adoption process and designed the back-end interview track.
2007 to 2019
Twelve years of client work, including Schiphol, where I led a move to TypeScript and Kafka that reached production in eight weeks, Buma/Stemra and NOS. Co-founded the web agency Ku and served as its technical lead.
The amount of energy needed to refute bullshit is an order of magnitude bigger than that needed to produce it.
There is nothing more permanent than a temporary solution.
What you do makes a difference, and you have to decide what kind of difference you want to make.
All models are wrong, but some are useful.