<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Marten on Coffee-Driven Development</title><link>https://duijzer.com/tags/marten/</link><description>Recent content in Marten on Coffee-Driven Development</description><generator>Hugo</generator><language>en-US</language><copyright>© {currentYear}, Jacob Duijzer. All rights reserved</copyright><lastBuildDate>Fri, 12 Jun 2026 16:14:19 +0200</lastBuildDate><atom:link href="https://duijzer.com/tags/marten/index.xml" rel="self" type="application/rss+xml"/><item><title>Event Sourcing with .NET and Marten</title><link>https://duijzer.com/posts/event-sourcing-with-dotnet-and-marten/</link><pubDate>Fri, 12 Jun 2026 00:00:00 +0200</pubDate><guid>https://duijzer.com/posts/event-sourcing-with-dotnet-and-marten/</guid><description>&lt;p&gt;The year 2026 began with unusually heavy snowfall in the Netherlands. It was more than we are used to, and in some cases enough to cause buildings to collapse.&lt;/p&gt;
&lt;p&gt;I work for an organization that provides Building Information Management services, so it made me think: what happens after a building collapses? There will probably be investigations into the specifications that were used at the time. Do we keep the full history? Do we know whether changes were made, why they were made, when they were made, and by whom?&lt;/p&gt;
&lt;p&gt;I had already been looking for a reason to dive into event sourcing, and this felt like a useful example. Event sourcing is not only about storing the current state of something, but about storing the facts that led to that state. That makes it a good fit for systems where history matters.&lt;/p&gt;
&lt;p&gt;In this post, I’ll use changing roof specifications as a small example to explain event sourcing, and show how it can be implemented in .NET with Marten.&lt;/p&gt;</description></item></channel></rss>