I work with teams to pin down what their software should do, then we build it. Event sourcing and event-driven architecture are my specialty.
I'm a Senior Consultant at Improving and a member of the JasperFx core team, where we build Marten, Wolverine, and other tools for .NET.
Software architecture and design: Event Modeling, Domain-Driven Design, and event-driven systems.
About me →Talks and workshops on event sourcing, software architecture, and the Critter Stack.
Talks →Core team on JasperFx's open-source Critter Stack, plus reference apps you can clone and argue with.
Open source →How I work
The spec says what the code should do. Where I use event sourcing, the event log records what it did.
Event Modeling is my preferred way in: developers and domain experts lay the business out on one timeline, and the spec is written from that. I use Domain-Driven Design to decide where one part of the system ends and the next begins.
Specification-Driven Development (SDD), mostly with OpenSpec. The spec is a human-readable contract of intent, constraints, and acceptance criteria that people and AI coding agents both build against. Agents that build from a spec don't have to guess.
Event sourcing and event-driven architecture where they fit, plain CRUD where they don't. .NET and the Critter Stack most days, the JVM or Node when that's what the team already uses. Evaluation-Driven Development (EDD) checks the agents' work: evals written up front score what they produce, so you know whether their output is right.
Latest talk
How a simple feature ended up scattered across a dozen files in a layered Clean Architecture, and what changed when an open-source .NET system moved to vertical slices. One bakery API built both ways and verified by one shared test suite, with A-Frame Architecture and Railway Oriented Programming along the way.
Writing and talks
How a simple feature ended up scattered across a dozen files in a layered Clean Architecture, and what changed when an open-source .NET system moved to vertical slices. One bakery API built both ways and verified by one shared test suite, with A-Frame Architecture and Railway Oriented Programming along the way.
Wolverine and Marten as an alternative to boilerplate-heavy .NET frameworks, and to the in-house mediator library that quietly grows into a framework of its own. You write plain C# methods; the libraries handle durable messaging, persistence, retries, and observability.
How a fast-growing ecommerce start-up adopted event sourcing, CQRS, and event-driven architecture, including the trade-offs, failures, and fixes that Hello World examples leave out.
The Domain-Driven Design view of an ecommerce business selling thousands of SKUs across dozens of marketplaces: why DDD, event sourcing, and CQRS were worth adopting there, and what they cost.
I recently launched a new YouTube channel focused on software development, design, and architecture!
I like hearing about systems that need to remember what happened.
Start a conversation