<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/">
  <channel>
    <title>Notes</title>
    <link>http://hugo.gandalfalex.de/</link>
    <description>Recent content on Notes</description>
    <generator>Hugo</generator>
    <language>en-us</language>
    <lastBuildDate>Tue, 05 May 2026 00:00:00 +0000</lastBuildDate>
    <atom:link href="http://hugo.gandalfalex.de/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>Architektur Dokumentation – Structured Notes</title>
      <link>http://hugo.gandalfalex.de/notes/architectur_structured/</link>
      <pubDate>Tue, 05 May 2026 00:00:00 +0000</pubDate>
      <guid>http://hugo.gandalfalex.de/notes/architectur_structured/</guid>
      <description>&lt;h1 id=&#34;architecture-documentation&#34;&gt;Architecture Documentation&lt;/h1&gt;
&lt;hr&gt;
&lt;h2 id=&#34;the-core-problem&#34;&gt;The Core Problem&lt;/h2&gt;
&lt;p&gt;Why architecture docs fail:&lt;/p&gt;
&lt;table&gt;
  &lt;thead&gt;
      &lt;tr&gt;
          &lt;th&gt;Problem&lt;/th&gt;
          &lt;th&gt;Why it happens&lt;/th&gt;
      &lt;/tr&gt;
  &lt;/thead&gt;
  &lt;tbody&gt;
      &lt;tr&gt;
          &lt;td&gt;Too much too early&lt;/td&gt;
          &lt;td&gt;Spec written before code — outdated by first sprint&lt;/td&gt;
      &lt;/tr&gt;
      &lt;tr&gt;
          &lt;td&gt;No time during development&lt;/td&gt;
          &lt;td&gt;Devs skip it under pressure, never catch up&lt;/td&gt;
      &lt;/tr&gt;
      &lt;tr&gt;
          &lt;td&gt;No ownership&lt;/td&gt;
          &lt;td&gt;Nobody is explicitly responsible → everyone assumes someone else does it&lt;/td&gt;
      &lt;/tr&gt;
      &lt;tr&gt;
          &lt;td&gt;Unclear scope&lt;/td&gt;
          &lt;td&gt;&amp;ldquo;What actually goes in there?&amp;rdquo; — no shared answer&lt;/td&gt;
      &lt;/tr&gt;
  &lt;/tbody&gt;
&lt;/table&gt;
&lt;p&gt;&lt;strong&gt;Solution framing:&lt;/strong&gt; Don&amp;rsquo;t ask &amp;ldquo;how do we document everything?&amp;rdquo; — ask &lt;strong&gt;&amp;ldquo;what and how do we document?&amp;rdquo;&lt;/strong&gt; Less is more. Document decisions and context, not implementation details the code already tells you.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Keynote – Structured Notes</title>
      <link>http://hugo.gandalfalex.de/notes/keynote_structured/</link>
      <pubDate>Tue, 05 May 2026 00:00:00 +0000</pubDate>
      <guid>http://hugo.gandalfalex.de/notes/keynote_structured/</guid>
      <description>&lt;h1 id=&#34;esdm--event-sourced-domain-modeling&#34;&gt;ESDM – Event-Sourced Domain Modeling&lt;/h1&gt;
&lt;p&gt;&lt;strong&gt;Website:&lt;/strong&gt; &lt;a href=&#34;https://www.esdm.io/&#34;&gt;https://www.esdm.io/&lt;/a&gt;&lt;br&gt;
&lt;strong&gt;Core idea:&lt;/strong&gt; Domain-first modeling language (YAML) that captures DDD, CQRS, and Event Sourcing building blocks in a machine- and human-readable format.&lt;/p&gt;
&lt;hr&gt;
&lt;h2 id=&#34;the-core-message&#34;&gt;The Core Message&lt;/h2&gt;
&lt;p&gt;&lt;strong&gt;Talk about domain first — technology is secondary.&lt;/strong&gt;&lt;/p&gt;
&lt;p&gt;Common mistake: teams jump to &amp;ldquo;we&amp;rsquo;ll use Kafka / PostgreSQL / microservices&amp;rdquo; before defining &lt;em&gt;what the system actually does&lt;/em&gt;. ESDM flips this:&lt;/p&gt;
&lt;ol&gt;
&lt;li&gt;Describe what happens in the domain (events, commands, rules)&lt;/li&gt;
&lt;li&gt;Model who triggers what and what results are needed&lt;/li&gt;
&lt;li&gt;Only then decide on tech stack&lt;/li&gt;
&lt;/ol&gt;
&lt;p&gt;This makes conversations with domain experts productive — they don&amp;rsquo;t need to understand Kafka to participate.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Observability: Monitoring &amp; Logging – Structured Notes</title>
      <link>http://hugo.gandalfalex.de/notes/does_my_app_work_structured/</link>
      <pubDate>Tue, 05 May 2026 00:00:00 +0000</pubDate>
      <guid>http://hugo.gandalfalex.de/notes/does_my_app_work_structured/</guid>
      <description>&lt;h1 id=&#34;observability-does-my-app-work&#34;&gt;Observability: Does My App Work?&lt;/h1&gt;
&lt;hr&gt;
&lt;h2 id=&#34;core-principle&#34;&gt;Core Principle&lt;/h2&gt;
&lt;p&gt;&lt;strong&gt;Balance:&lt;/strong&gt; Not too much, not too little. Every metric and log must answer a real operational question.&lt;/p&gt;
&lt;hr&gt;
&lt;h2 id=&#34;monitoring&#34;&gt;Monitoring&lt;/h2&gt;
&lt;h3 id=&#34;the-right-amount&#34;&gt;The Right Amount&lt;/h3&gt;
&lt;p&gt;Use &lt;strong&gt;Icinga&lt;/strong&gt; (as already deployed in your infrastructure) and focus on:&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;Where can we take action if something breaks?&lt;/li&gt;
&lt;li&gt;Where is the signal-to-noise ratio actually worth it?&lt;/li&gt;
&lt;/ul&gt;
&lt;p&gt;&lt;strong&gt;Question every metric:&lt;/strong&gt; If this threshold fires, can we do something about it in 30 seconds? If not, it&amp;rsquo;s noise.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Workshop – Structured Notes</title>
      <link>http://hugo.gandalfalex.de/notes/workshop_structured/</link>
      <pubDate>Tue, 05 May 2026 00:00:00 +0000</pubDate>
      <guid>http://hugo.gandalfalex.de/notes/workshop_structured/</guid>
      <description>&lt;h1 id=&#34;spring-ddd--architecture-workshop-notes&#34;&gt;Spring, DDD &amp;amp; Architecture Workshop Notes&lt;/h1&gt;
&lt;hr&gt;
&lt;h2 id=&#34;spring-security-upcoming-fixes-may-18&#34;&gt;Spring Security: Upcoming Fixes (May 18)&lt;/h2&gt;
&lt;p&gt;&lt;strong&gt;Rollout date: 18. Mai&lt;/strong&gt;&lt;/p&gt;
&lt;p&gt;Spring releases a batch of security fixes discovered via the &lt;strong&gt;Mythos vulnerability check&lt;/strong&gt;. All branches up to &lt;strong&gt;Spring 2.7&lt;/strong&gt; are affected.&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;Blog post with full details drops next week&lt;/li&gt;
&lt;li&gt;If you run anything ≤ 2.7, plan the upgrade now&lt;/li&gt;
&lt;li&gt;Full talk at &lt;strong&gt;DevOps Antwerpen&lt;/strong&gt; covers this in depth&lt;/li&gt;
&lt;/ul&gt;
&lt;hr&gt;
&lt;h2 id=&#34;domain-driven-design-ddd&#34;&gt;Domain-Driven Design (DDD)&lt;/h2&gt;
&lt;h3 id=&#34;extensional-vs-intensional&#34;&gt;Extensional vs. Intensional&lt;/h3&gt;
&lt;table&gt;
  &lt;thead&gt;
      &lt;tr&gt;
          &lt;th&gt;Term&lt;/th&gt;
          &lt;th&gt;Meaning&lt;/th&gt;
          &lt;th&gt;Examples&lt;/th&gt;
      &lt;/tr&gt;
  &lt;/thead&gt;
  &lt;tbody&gt;
      &lt;tr&gt;
          &lt;td&gt;&lt;strong&gt;Extensional&lt;/strong&gt;&lt;/td&gt;
          &lt;td&gt;Represents external reality — maps things from outside the domain&lt;/td&gt;
          &lt;td&gt;DTOs, API models, database rows&lt;/td&gt;
      &lt;/tr&gt;
      &lt;tr&gt;
          &lt;td&gt;&lt;strong&gt;Intensional&lt;/strong&gt;&lt;/td&gt;
          &lt;td&gt;Expresses domain concepts from within — gives things meaning&lt;/td&gt;
          &lt;td&gt;Value Objects, Entities, Aggregates&lt;/td&gt;
      &lt;/tr&gt;
  &lt;/tbody&gt;
&lt;/table&gt;
&lt;p&gt;The goal: code that reads like the domain language, not like database schema.&lt;/p&gt;</description>
    </item>
  </channel>
</rss>
