feat: add DRY and Event Storming anchors

docs/anchors/dry.adoc

@@ -0,0 +1,51 @@
+= DRY (Don't Repeat Yourself)
+:categories: design-principles
+:roles: software-developer, software-architect, educator
+:related: ssot-principle, single-level-of-abstraction-principle, kiss-principle, yagni
+:proponents: Andy Hunt, Dave Thomas
+:tags: dry, dont-repeat-yourself, duplication, knowledge, abstraction, maintainability
+:tier: 3
+
+[%collapsible]
+====
+Full Name:: Don't Repeat Yourself
+
+Also known as:: DRY Principle; antonym: WET ("Write Everything Twice" / "We Enjoy Typing")
+
+[discrete]
+== *Core Concepts*:
+
+The principle:: "Every piece of knowledge must have a single, unambiguous, authoritative representation within a system." One fact — a business rule, a constant, a schema — lives in exactly one place
+
+Knowledge, not code:: DRY targets duplicated *knowledge/intent*, not coincidental textual similarity. Two code fragments that look alike but change for different reasons are not a DRY violation; collapsing them couples unrelated concerns
+
+Single source of truth:: Derive rather than restate — generate docs/config/clients from one authoritative definition so a change propagates instead of being copied
+
+Rule of Three:: Extract a shared abstraction after the *third* occurrence, not the first (Martin Fowler). Premature de-duplication guesses at an abstraction before the pattern is clear
+
+The wrong-abstraction caution:: "Duplication is far cheaper than the wrong abstraction" (Sandi Metz). A bad shared abstraction couples callers and is harder to unwind than the duplication it removed — prefer duplication until the right seam is obvious
+
+Key Proponents:: Andy Hunt & Dave Thomas, *The Pragmatic Programmer* (1999)
+
+[discrete]
+== *When to Use*:
+
+* Consolidating a business rule, constant, or schema that appears in several places
+* Designing a single source of truth (config, types, API contracts) that other artifacts derive from
+* Reviewing code for knowledge duplication that causes change to require edits in many spots
+
+[discrete]
+== *When NOT to Use*:
+
+* Before the Rule of Three — resist abstracting on the first or second occurrence
+* When two similar fragments change for different reasons — coupling them via a shared abstraction is worse than the duplication
+* As dogma over readability: a little duplication can beat a leaky, over-general abstraction
+
+[discrete]
+== *Related Anchors*:
+
+* <<ssot-principle,Single Source of Truth>> — the data-layer cousin of DRY's knowledge rule
+* <<single-level-of-abstraction-principle,Single Level of Abstraction Principle>> — keeps extracted abstractions coherent
+* <<kiss-principle,KISS Principle>> — the simplicity counterweight to over-abstraction
+* <<yagni,YAGNI>> — don't build the abstraction until you actually need it
+====

docs/anchors/dry.de.adoc

@@ -0,0 +1,51 @@
+= DRY (Don't Repeat Yourself)
+:categories: design-principles
+:roles: software-developer, software-architect, educator
+:related: ssot-principle, single-level-of-abstraction-principle, kiss-principle, yagni
+:proponents: Andy Hunt, Dave Thomas
+:tags: dry, dont-repeat-yourself, duplication, knowledge, abstraction, maintainability
+:tier: 3
+
+[%collapsible]
+====
+Vollständiger Name:: Don't Repeat Yourself
+
+Auch bekannt als:: DRY-Prinzip; Gegenstück: WET („Write Everything Twice" / „We Enjoy Typing")
+
+[discrete]
+== *Kernkonzepte*:
+
+Das Prinzip:: „Every piece of knowledge must have a single, unambiguous, authoritative representation within a system." Ein Fakt — eine Geschäftsregel, eine Konstante, ein Schema — lebt an genau einer Stelle
+
+Wissen, nicht Code:: DRY zielt auf dupliziertes *Wissen/Intention*, nicht auf zufällige textuelle Ähnlichkeit. Zwei ähnlich aussehende Fragmente, die sich aus unterschiedlichen Gründen ändern, sind keine DRY-Verletzung; sie zusammenzulegen koppelt unverwandte Belange
+
+Single Source of Truth:: Ableiten statt wiederholen — Doku/Config/Clients aus einer maßgeblichen Definition generieren, damit eine Änderung sich fortpflanzt statt kopiert zu werden
+
+Rule of Three:: Eine gemeinsame Abstraktion erst beim *dritten* Auftreten extrahieren, nicht beim ersten (Martin Fowler). Verfrühtes Entdoppeln rät die Abstraktion, bevor das Muster klar ist
+
+Warnung vor der falschen Abstraktion:: „Duplication is far cheaper than the wrong abstraction" (Sandi Metz). Eine schlechte gemeinsame Abstraktion koppelt die Aufrufer und ist schwerer aufzulösen als die entfernte Duplizierung — lieber duplizieren, bis die richtige Naht offensichtlich ist
+
+Key Proponents:: Andy Hunt & Dave Thomas, *The Pragmatic Programmer* (1999)
+
+[discrete]
+== *Verwendung*:
+
+* Konsolidierung einer Geschäftsregel, Konstante oder eines Schemas, das an mehreren Stellen auftaucht
+* Entwurf einer Single Source of Truth (Config, Typen, API-Contracts), aus der andere Artefakte abgeleitet werden
+* Code-Review auf Wissensduplizierung, die Änderungen an vielen Stellen erzwingt
+
+[discrete]
+== *Nicht verwenden*:
+
+* Vor der Rule of Three — beim ersten oder zweiten Auftreten nicht abstrahieren
+* Wenn zwei ähnliche Fragmente sich aus unterschiedlichen Gründen ändern — Kopplung über eine gemeinsame Abstraktion ist schlimmer als die Duplizierung
+* Als Dogma über Lesbarkeit: etwas Duplizierung schlägt eine undichte, übergeneralisierte Abstraktion
+
+[discrete]
+== *Verwandte Anker*:
+
+* <<ssot-principle,Single Source of Truth>> — der Daten-Vetter von DRYs Wissensregel
+* <<single-level-of-abstraction-principle,Single Level of Abstraction Principle>> — hält extrahierte Abstraktionen kohärent
+* <<kiss-principle,KISS Principle>> — das Einfachheits-Gegengewicht zur Über-Abstraktion
+* <<yagni,YAGNI>> — die Abstraktion erst bauen, wenn sie wirklich gebraucht wird
+====

docs/anchors/event-storming.adoc

@@ -0,0 +1,53 @@
+= Event Storming according to Alberto Brandolini
+:categories: requirements-engineering, software-architecture
+:roles: software-architect, business-analyst, product-owner, consultant, team-lead
+:related: domain-driven-design, user-story-mapping, cqrs, event-driven-architecture
+:proponents: Alberto Brandolini
+:tags: event-storming, ddd, domain-events, collaborative-workshop, bounded-contexts, aggregates, big-picture, design-level, process-modeling
+:tier: 3
+
+[%collapsible]
+====
+Full Name:: Event Storming
+
+Also known as:: EventStorming (Brandolini)
+
+[discrete]
+== *Core Concepts*:
+
+Domain events on a timeline:: Model the domain as past-tense *domain events* (orange stickies) placed left-to-right on a wide wall, reconstructing how the business actually unfolds over time
+
+The colour notation:: A fixed sticky vocabulary — orange = Domain Event, blue = Command, yellow = Aggregate, lilac = Policy (reactive "whenever… then…"), green = Read Model, pink = External System, red = Hotspot (conflict, question, assumption)
+
+Three levels:: *Big Picture* (explore the whole domain with all stakeholders), *Process Modeling* (zoom into one flow: command → event → policy → command), *Design Level* (aggregates, commands and events detailed enough to drive implementation)
+
+Pivotal events:: Events that mark phase transitions or boundaries — strong candidates for *bounded context* seams
+
+Hotspots:: Make conflicts, unknowns and assumptions explicit on the wall instead of glossing over them — they become the agenda
+
+Chaotic exploration → enforced timeline:: Everyone adds events in parallel first (diverge), then the group orders and de-duplicates them into a coherent line (converge)
+
+Key Proponents:: Alberto Brandolini (first run 2012, "Introducing EventStorming" blog post 2013; Leanpub book, continuously updated)
+
+[discrete]
+== *When to Use*:
+
+* Kicking off a Domain-Driven Design effort — discovering bounded contexts and aggregate boundaries collaboratively
+* Aligning business and engineering on a shared, visual domain model
+* Before deciding on an event-driven or CQRS architecture — discover the events/commands first
+* *Reverse Event Storming* on legacy systems (well suited to an AI agent): extract state transitions → map to Domain Events → cluster into Aggregates → surface Bounded Contexts
+
+[discrete]
+== *When NOT to Use*:
+
+* Trivial CRUD domains with no meaningful process or business rules
+* Solo modeling where the collaborative, cross-role discovery — the whole point — is absent
+
+[discrete]
+== *Related Anchors*:
+
+* <<domain-driven-design,Domain-Driven Design>> — the vocabulary (aggregates, bounded contexts) Event Storming discovers; often the on-ramp to DDD
+* <<user-story-mapping,User Story Mapping>> — activity-centric mapping vs. event-centric discovery
+* <<cqrs,CQRS>> — commands and read models found on the wall feed a later CQRS decision
+* <<event-driven-architecture,Event-Driven Architecture>> — the modeling step that precedes deciding how events are routed
+====

docs/anchors/event-storming.de.adoc

@@ -0,0 +1,53 @@
+= Event Storming according to Alberto Brandolini
+:categories: requirements-engineering, software-architecture
+:roles: software-architect, business-analyst, product-owner, consultant, team-lead
+:related: domain-driven-design, user-story-mapping, cqrs, event-driven-architecture
+:proponents: Alberto Brandolini
+:tags: event-storming, ddd, domain-events, collaborative-workshop, bounded-contexts, aggregates, big-picture, design-level, process-modeling
+:tier: 3
+
+[%collapsible]
+====
+Vollständiger Name:: Event Storming
+
+Auch bekannt als:: EventStorming (Brandolini)
+
+[discrete]
+== *Kernkonzepte*:
+
+Domain Events auf einer Zeitachse:: Die Domäne als *Domain Events* in der Vergangenheitsform (orange Stickies) modellieren, von links nach rechts auf einer breiten Wand — so wird rekonstruiert, wie das Geschäft tatsächlich über die Zeit abläuft
+
+Die Farb-Notation:: Ein festes Sticky-Vokabular — orange = Domain Event, blau = Command, gelb = Aggregate, lila = Policy (reaktives „immer wenn… dann…"), grün = Read Model, pink = External System, rot = Hotspot (Konflikt, Frage, Annahme)
+
+Drei Ebenen:: *Big Picture* (die ganze Domäne mit allen Stakeholdern erkunden), *Process Modeling* (in einen Fluss zoomen: Command → Event → Policy → Command), *Design Level* (Aggregates, Commands und Events detailliert genug zur Implementierung)
+
+Pivotal Events:: Events, die Phasenübergänge oder Grenzen markieren — starke Kandidaten für *Bounded-Context*-Nahtstellen
+
+Hotspots:: Konflikte, Unbekanntes und Annahmen explizit an der Wand machen, statt sie zu übergehen — sie werden zur Agenda
+
+Chaotische Exploration → erzwungene Zeitachse:: Erst fügen alle parallel Events hinzu (divergieren), dann ordnet und entdoppelt die Gruppe sie zu einer kohärenten Linie (konvergieren)
+
+Key Proponents:: Alberto Brandolini (erster Lauf 2012, Blogpost „Introducing EventStorming" 2013; Leanpub-Buch, laufend aktualisiert)
+
+[discrete]
+== *Verwendung*:
+
+* Start eines Domain-Driven-Design-Vorhabens — Bounded Contexts und Aggregate-Grenzen kollaborativ entdecken
+* Business und Engineering auf ein gemeinsames, visuelles Domänenmodell ausrichten
+* Vor der Entscheidung für eine Event-Driven- oder CQRS-Architektur — zuerst die Events/Commands entdecken
+* *Reverse Event Storming* an Legacy-Systemen (gut für einen AI-Agenten geeignet): Zustandsübergänge extrahieren → auf Domain Events abbilden → zu Aggregates clustern → Bounded Contexts sichtbar machen
+
+[discrete]
+== *Nicht verwenden*:
+
+* Triviale CRUD-Domänen ohne nennenswerten Prozess oder Geschäftsregeln
+* Solo-Modellierung, bei der die kollaborative, rollenübergreifende Entdeckung — der eigentliche Zweck — fehlt
+
+[discrete]
+== *Verwandte Anker*:
+
+* <<domain-driven-design,Domain-Driven Design>> — das Vokabular (Aggregates, Bounded Contexts), das Event Storming entdeckt; oft der Einstieg in DDD
+* <<user-story-mapping,User Story Mapping>> — aktivitätszentrierte Abbildung vs. event-zentrierte Entdeckung
+* <<cqrs,CQRS>> — an der Wand gefundene Commands und Read Models speisen eine spätere CQRS-Entscheidung
+* <<event-driven-architecture,Event-Driven Architecture>> — der Modellierungsschritt, der dem Routing der Events vorausgeht
+====

docs/changelog.adoc

@@ -2,6 +2,13 @@
 
 A chronological record of all semantic anchors added to the catalog. Community contributors are credited with thanks.
 
+== 2026-06-02
+
+*New anchors:*
+
+* *DRY (Don't Repeat Yourself)* — "every piece of knowledge must have a single, unambiguous, authoritative representation within a system"; targets duplicated knowledge/intent rather than coincidental textual similarity, with the Rule of Three (Fowler) and the wrong-abstraction caution ("duplication is far cheaper than the wrong abstraction", Sandi Metz) as guardrails; antonym WET (Andy Hunt & Dave Thomas, *The Pragmatic Programmer*, 1999; proposed by https://github.com/GaboCapo[@GaboCapo] in https://github.com/LLM-Coding/Semantic-Anchors/issues/560[#560])
+* *Event Storming according to Alberto Brandolini* — a collaborative workshop that models a domain as past-tense domain events on a timeline using a fixed colour notation (orange Event, blue Command, yellow Aggregate, lilac Policy, green Read Model, pink External System, red Hotspot) across three levels (Big Picture, Process Modeling, Design Level); surfaces bounded-context seams via pivotal events and makes assumptions explicit as hotspots; Reverse Event Storming reconstructs legacy systems (Alberto Brandolini, 2012/2013; proposed by https://github.com/SidekickJohn[@SidekickJohn] in https://github.com/LLM-Coding/Semantic-Anchors/issues/558[#558])
+
 == 2026-06-01
 
 *New anchors:*

skill/semantic-anchor-translator/references/catalog.md

@@ -188,6 +188,11 @@ Source: https://github.com/LLM-Coding/Semantic-Anchors
 
 ## Design Principles
 
+### DRY (Don't Repeat Yourself)
+- **Also known as:** DRY Principle; antonym WET ("Write Everything Twice" / "We Enjoy Typing")
+- **Proponents:** Andy Hunt & Dave Thomas (*The Pragmatic Programmer*, 1999)
+- **Core:** Every piece of knowledge must have a single, unambiguous, authoritative representation within a system; targets duplicated knowledge/intent, not coincidental textual similarity; pair with the Rule of Three (Fowler) and the wrong-abstraction caution ("duplication is far cheaper than the wrong abstraction", Sandi Metz) to avoid premature, leaky abstractions
+
 ### Law of Demeter
 - **Also known as:** Principle of Least Knowledge, "Don't talk to strangers"
 - **Proponents:** Ian Holland & Karl Lieberherr (Northeastern University, 1987)
@@ -451,6 +456,11 @@ Source: https://github.com/LLM-Coding/Semantic-Anchors
 - **Proponents:** Alistair Cockburn
 - **Core:** Structured textual use case format — Primary Actor, Stakeholders & Interests, Preconditions, Trigger, Main Success Scenario, Extensions, Postconditions; three Goal Levels (Summary/Kite, User Goal/Sea Level, Subfunction/Fish); Actor-Goal List as discovery technique; deliberately prose-based and notation-agnostic — does NOT prescribe Activity Diagrams, Gherkin, or EARS, which are complementary representations
 
+### Event Storming according to Alberto Brandolini
+- **Also known as:** EventStorming
+- **Proponents:** Alberto Brandolini (2012/2013)
+- **Core:** Collaborative workshop that models a domain as past-tense domain events on a timeline using a fixed colour notation (orange Event, blue Command, yellow Aggregate, lilac Policy, green Read Model, pink External System, red Hotspot); runs at three levels (Big Picture, Process Modeling, Design Level); surfaces bounded-context seams via pivotal events and makes assumptions explicit as hotspots; Reverse Event Storming reconstructs legacy systems
+
 ### INVEST
 - **Proponents:** Bill Wake
 - **Core:** Independent, Negotiable, Valuable, Estimable, Small, Testable — criteria for well-formed user stories

website/public/data/anchors.json

@@ -678,6 +678,38 @@
     "filePath": "docs/anchors/double-diamond.adoc",
     "tier": 3
   },
+  {
+    "id": "dry",
+    "title": "DRY (Don’t Repeat Yourself)",
+    "categories": [
+      "design-principles"
+    ],
+    "roles": [
+      "software-developer",
+      "software-architect",
+      "educator"
+    ],
+    "related": [
+      "ssot-principle",
+      "single-level-of-abstraction-principle",
+      "kiss-principle",
+      "yagni"
+    ],
+    "proponents": [
+      "Andy Hunt",
+      "Dave Thomas"
+    ],
+    "tags": [
+      "dry",
+      "dont-repeat-yourself",
+      "duplication",
+      "knowledge",
+      "abstraction",
+      "maintainability"
+    ],
+    "filePath": "docs/anchors/dry.adoc",
+    "tier": 3
+  },
   {
     "id": "ears-requirements",
     "title": "EARS-Requirements",
@@ -755,6 +787,43 @@
     "filePath": "docs/anchors/event-driven-architecture.adoc",
     "tier": 3
   },
+  {
+    "id": "event-storming",
+    "title": "Event Storming according to Alberto Brandolini",
+    "categories": [
+      "requirements-engineering",
+      "software-architecture"
+    ],
+    "roles": [
+      "software-architect",
+      "business-analyst",
+      "product-owner",
+      "consultant",
+      "team-lead"
+    ],
+    "related": [
+      "domain-driven-design",
+      "user-story-mapping",
+      "cqrs",
+      "event-driven-architecture"
+    ],
+    "proponents": [
+      "Alberto Brandolini"
+    ],
+    "tags": [
+      "event-storming",
+      "ddd",
+      "domain-events",
+      "collaborative-workshop",
+      "bounded-contexts",
+      "aggregates",
+      "big-picture",
+      "design-level",
+      "process-modeling"
+    ],
+    "filePath": "docs/anchors/event-storming.adoc",
+    "tier": 3
+  },
   {
     "id": "fagan-inspection",
     "title": "Fagan Inspection",

website/public/data/categories.json

@@ -34,6 +34,7 @@
       "code-smells",
       "cohesion-criteria",
       "crc-cards",
+      "dry",
       "fowler-patterns",
       "gof-abstract-factory-pattern",
       "gof-adapter-pattern",
@@ -157,6 +158,7 @@
       "cockburn-use-cases",
       "double-diamond",
       "ears-requirements",
+      "event-storming",
       "invest",
       "kano-model",
       "moscow",
@@ -180,6 +182,7 @@
       "cqrs",
       "domain-driven-design",
       "event-driven-architecture",
+      "event-storming",
       "fallacies-of-distributed-computing",
       "gom",
       "hexagonal-architecture",