Coada — Writing

The Jobs Aren't Back. They're Different Jobs.

Thu, 09 Apr 2026 23:27:50 GMT

The headlines are warm again.

Software engineering roles have doubled since mid-2023. Sixty-seven thousand open positions. Listings up 11% year-over-year. Three openings for every qualified candidate. Salary growth averaging 4.2%.

If you're reading those numbers from a hiring desk, the crisis is over. If you're reading them from a couch where you've been sitting for fourteen months sending applications into a void, the crisis hasn't even started being honest with you yet.

The Counting Problem

The Bureau of Labor Statistics counts an opening. It doesn't ask whether the person who just lost their job at that same company can fill it.

Indeed counts a listing. It doesn't track how many of those listings sit open for nine months because the company would rather leave a seat empty than hire someone who needs to be retrained.

When a company says "we have three openings for every qualified candidate," that's not a labor shortage. That's a skills mismatch being reported as a market recovery.

Here's how the math actually works. A Fortune 500 cuts 400 mid-level engineers in January. Posts 200 "AI-native platform engineer" roles in March. The net looks like growth. The headlines report recovery. And 400 people who built production systems for a decade are still unemployed, watching job boards full of openings they don't qualify for.

That's not recovery. That's replacement.

What Actually Changed in Three Years

The job that got eliminated didn't get reinstated. It got restructured into something the person who held it might not recognize.

Three years ago, the market valued the engineer who could write React components and ship features on a two-week sprint cadence. That job is compressed now. AI handles the output layer. What's left is the judgment layer — system design, domain modeling, integration architecture, failure mode analysis, trade-off reasoning under ambiguity.

The people who thrived writing code are not automatically the people who thrive deciding what code should exist.

That's not a semantic distinction. It's a career-ending one for a lot of people who were very good at their jobs.

The Cross-Disciplinary Divide

Watch who's actually landing in the new market. It's not the deepest specialists. It's the widest thinkers.

The developer who also understood product. The backend engineer who also did infrastructure. The architect who'd sat in sales calls and heard what the customer actually needed versus what the ticket said.

They didn't just learn to code. They learned to think across boundaries. And now, paired with AI, those people are producing output that would have required a team of six three years ago.

Meanwhile, the engineer who spent a decade getting exceptionally good at one framework, one layer of the stack, one narrow slice of the pipeline — that expertise was valuable when the floor existed.

The floor is gone.

The Retraining Lie

Every time a market shifts like this, the same reassurance shows up: "People just need to reskill." It sounds reasonable. It's almost never true at the pace the market demands.

Architecture isn't a certification. Lateral thinking isn't a bootcamp. The judgment that makes someone valuable in the current market was built over years of cross-disciplinary work — product decisions, infrastructure trade-offs, customer conversations, failed projects, recovered projects.

You can't speedrun that.

A six-month AI engineering course doesn't give you the instinct to know when an architecture will collapse under scale. Watching a tutorial on system design doesn't teach you how to make trade-offs between consistency and availability while a product manager is staring at you waiting for a yes. Those are skills you earn by being wrong enough times to recognize the shape of the next mistake before you make it.

The people telling displaced engineers to "just learn AI" are offering the same advice as telling a taxi driver to "just become a software engineer" in 2014. Technically possible. Statistically rare. And the people giving the advice are never the ones who have to take it.

Who the Numbers Are Actually Counting

Let's be precise about what "67,000 open positions" means.

It means companies are building AI products and need engineers to build them. It means the demand is real. None of that is in dispute.

What's in dispute is who those jobs are for.

They're for engineers who already think in systems. Who already model domains. Who already design for failure. Who already understand distributed architecture, event-driven patterns, and the difference between structural correctness and semantic correctness.

They're not for the mid-level developer who shipped features reliably for eight years and suddenly finds that "reliable feature shipping" is exactly the job AI compresses first.

The cruelty of this market is that the people it displaced are often genuinely good engineers. They didn't fail. The definition of the job changed underneath them. And the new definition requires a fundamentally different kind of thinking that takes years to develop — years they may not have, because the market moved in months.

The Uncomfortable Part

When someone says "AI won't replace developers, it'll just change what developers do" — that's a comforting lie dressed up as optimism.

AI is already replacing developers. Entire categories of engineering output that required human labor eighteen months ago are now handled by tools that didn't exist then. The companies doing the replacing are the same ones posting those 67,000 job openings. They're not contradicting themselves. They're replacing one kind of engineer with a different kind.

The honest framing isn't "the jobs are back." It's: "new jobs exist, and they require capabilities that a large portion of the displaced workforce doesn't have."

That's not a recovery. That's a restructuring. And a restructuring without an honest accounting of who's left behind isn't optimism. It's negligence.

What the Numbers Won't Tell You

They won't tell you about the senior engineer with fifteen years of experience who's been interviewing for eleven months and keeps getting rejected for roles that didn't exist when they were laid off.

They won't tell you about the teams that post openings they never intend to fill — headcount budget theater for the board while the actual work gets absorbed by three people and an AI tool.

They won't tell you about the companies lowballing experienced engineers 50 to 70 percent below market rate, because a flooded market means someone desperate enough will take it.

They won't tell you that "three openings for every qualified candidate" is an indictment, not a celebration. It means the market broke the pipeline. It spent three years laying off the mid-career engineers who would have been next in line, and now it's shocked that there's nobody to fill the senior roles.

You don't get to gut the middle of the ladder and then complain about a talent shortage at the top.

The Real Question

The real question isn't whether engineering jobs are "back." It's whether the industry is willing to be honest about what it did.

It overhired during a bubble. It cut aggressively to protect stock prices. It blamed AI for decisions that were really about margins. And now it's celebrating "recovery" while a generation of mid-career engineers — people who built the systems these companies run on — sit on the other side of a skills gap that didn't exist three years ago.

The jobs aren't back. Different jobs showed up. And the people who lost the old ones are being told the market is fine while staring at a wall of postings they can't qualify for.

That's not recovery. That's denial with a press release.

Stop counting openings. Start counting placements. The gap between those two numbers is the actual state of the engineering market — and nobody wants to talk about it.

I Stopped Correcting 40% of My AI's Work.

Wed, 08 Apr 2026 07:40:08 GMT

Here's What Changed.

I run product and engineering for regulated healthcare software. Over the past year, I've shipped three products using AI as a core member of the delivery team — not for code suggestions or autocomplete, but for full execution: architecture, domain modeling, compliance documentation, sprint planning, pull requests.

Early on, I was correcting roughly 40% of what the AI delivered. Not hallucinations or obvious errors — structural misalignment. The code was clean, the documents were well-written, and the logic was sound. But 4 out of 10 deliverables didn't match the intent. A story would be implemented against the wrong architectural assumption. A document would reference a pattern we'd discussed but never decided on. A pull request would make a reasonable judgment call that happened to be the wrong one.

That 40% correction rate was consistent across projects, across domains, across complexity levels. It wasn't a capability problem. It was a structural one.

Today, across three shipped products, that number is roughly 5%.

The difference isn't a better model. It's a methodology.

The Problem Isn't Intelligence. It's Ambiguity.

When you hand an AI a story that says "implement the patient authorization flow," the AI will deliver something. It will make decisions about state management, error handling, API boundaries, security constraints, and data persistence. It will make those decisions confidently, because that's what large language models do — they produce plausible outputs.

The problem is that "plausible" and "correct" diverge exactly at the decision points that matter most. The AI doesn't know that your team decided last month to isolate token storage in a dedicated service. It doesn't know that your compliance framework requires audit events at the command level, not the API level. It doesn't know that the domain expert deferred the acuity algorithm to a later phase, so the placeholder invariant in the spec is intentional, not an oversight.

Every ambiguous decision point in a ticket is a coin flip. The AI will resolve it, but it won't tell you it's guessing. And the resolution will be internally consistent, well-documented, and wrong in ways that require deep domain knowledge to catch.

This is why smarter models don't fix the problem. The bottleneck was never reasoning capability. It was the absence of explicit, locked decisions upstream of execution.

Three Layers That Eliminated Guessing

I built a methodology — iteratively, over the course of these three products — that moves every material decision upstream of execution. It has three layers, and they must be completed in sequence.

Layer 1: Regulatory Foundation

Before any product design work begins, the compliance scaffolding gets built. For healthcare, that means a complete Quality Management System: policies, standard operating procedures, forms, evidence records, and a control mapping to whatever regulatory framework applies.

This isn't checkbox compliance. Every SOP becomes a governing document that execution references. When a story says "per SOP-014," that SOP exists, it's specific to the organization's architecture and tooling, and it defines exactly what evidence the story must produce. The AI doesn't interpret regulatory requirements at implementation time — the interpretation was done during the compliance authoring phase and locked in a controlled document.

On the first product, a two-person team (me and the AI) produced 50 controlled documents in roughly 30 hours. Traditional timeline for that scope is 4–6 weeks with a dedicated compliance team.

Layer 2: Signal-Driven Design

This is where the product's architecture gets defined — not as a set of diagrams or a PRD that engineering interprets, but as a formal domain model that converges to zero ambiguity through iterative adversarial passes. I call this methodology Signal-Driven Design (SDD).

SDD draws from domain-driven design, event storming, and user journey mapping, but its core mechanic is adversarial convergence. The process works like this:

Extract a domain specification from the PRD and architectural decision records. This produces bounded contexts, aggregates, commands, events, invariants, policies, and sagas — the full vocabulary of what the system does.
Run an adversarial gap analysis against the specification you just produced. The same session that wrote the spec tries to break it: structural gaps (missing aggregates, orphaned events), heuristic gaps (oversized aggregates, thin contexts), language gaps (inconsistent terminology), and decision gaps (unresolved architectural questions).
Resolve every gap collaboratively, one at a time. Some are mechanical fixes the AI handles as an interpreter. Others require architectural judgment — those escalate to me. The role separation is explicit: the AI proposes, I decide, and the decision gets recorded with rationale.
Regenerate the full specification incorporating all resolutions and run the adversarial analysis again. Repeat until gaps hit zero.

On every product, this converges in three passes. The gap trajectory is predictable by pass two — you can see whether the model is tightening or oscillating. What matters is that when it converges, every command, every event, every invariant has been examined adversarially and either confirmed or corrected. There are no assumptions left in the specification.

The items that can't be resolved — because a domain expert hasn't made the call yet, or a technical evaluation hasn't happened — go into a deferred resolutions tracker with an explicit owner. They don't get guessed at. They get flagged as implementation-blocking and carried forward visibly.

Layer 3: Execution Planning With Closed Boundaries and Enforced Quality Gates

The converged domain specification feeds into an execution plan manifest — a single document that maps every milestone, epic, and story to the domain model, the governing ADRs, and the regulatory SOPs. Every story has:

A closed boundary defining exactly which files it creates, modifies, or reads
Machine-verifiable exit criteria tied to the domain specification
References to the specific governing documents that define how it's built
Parallelization tags based on file-level conflict analysis between stories

But the manifest alone is just a document. What makes it enforceable is the CI pipeline.

Every quality gate from the methodology gets encoded into continuous integration. Coverage thresholds, test evidence requirements, traceability checks, linting rules that enforce architectural boundaries — these run on every pull request, automatically, without human intervention. The pipeline doesn't care who wrote the code. It validates that the output conforms to the specification and the governing documents.

This is what keeps execution, tracking, and the AI in sync. You can cut corners, but the quality gates will catch you. A story that skips its test specification fails CI. A pull request that modifies files outside its closed boundary fails CI. Code that doesn't meet coverage thresholds fails CI. The methodology's discipline isn't enforced by willpower or code review — it's enforced mechanically, on every commit.

The manifest becomes the contract between planning and execution. When the AI picks up a story, it doesn't need to make architectural decisions — every decision was already made during layer 2, documented in an ADR, and referenced on the ticket. The AI's job is translation: take the locked specification and produce code that matches it. And CI verifies that the translation is faithful.

This is the key insight: the framework doesn't make the executor smarter. It makes the executor's judgment irrelevant to the outcome.

What the Numbers Actually Mean

The 95% accuracy rate isn't the AI getting things right 95% of the time through better reasoning. It's the AI having nothing to get wrong. When every decision is locked in a governing document, every story has a closed boundary, and every invariant has been adversarially validated, the implementation is a mechanical translation exercise. The 5% that still requires correction is edge cases where the specification was ambiguous in ways the gap analysis didn't catch — and those corrections feed back into the next pass.

The 40% correction rate without the framework isn't the AI being bad at coding. It's the AI being confident at guessing. Remove the guessing, and the number drops to the floor.

My time split now is roughly 60% planning (working through the three layers with the AI as a collaborator) and 40% delivery oversight. That 40% isn't debugging code line by line. It's reviewing pull requests for shape, reading CI reports, checking test coverage summaries, and confirming that the pipeline's quality gates passed cleanly. When enough quality is locked into CI, I defer my trust to the reporting of the pipeline jobs rather than having to validate implementation details myself. The planning investment is front-loaded and significant. But the delivery phase is fast, predictable, and the reviews are architectural confirmations rather than defect hunts.

What This Changes About AI-Augmented Teams

Yes, code is cheap. AI can produce it faster than any human team, and the quality floor keeps rising with every model generation. But producing code was never the hard part.

The hard part is knowing what to build and why. It's tying together domain-driven design, event storming, user journey mapping, product management, architecture, engineering, testing, and compliance into a coherent system where every decision reinforces every other decision. That cross-discipline integration doesn't come from a tool. It comes from years of building things, shipping things, breaking things, and learning which decisions cascade and which ones don't.

There's no bootcamp for this. No certificate course. No fast path. It's the accumulated judgment of someone who has been a product owner, an architect, a quality manager, and a compliance officer — often simultaneously — and who understands how those roles constrain and inform each other. The methodology I've described isn't a process anyone can follow mechanically. It requires someone who can see the gap between a domain specification and a regulatory requirement, between an architectural decision and its downstream impact on sales cycles, between a testing strategy and its evidence value during an audit.

AI is contextually aware of the now. It can reason about the specification in front of it with remarkable depth. But it doesn't see how today's decisions shape the product six months from now. It doesn't know that shifting regulatory compliance left — building it into the foundation instead of retrofitting it — puts a business at the front of the line in competitive markets where enterprise buyers require certification before the first demo. It doesn't know that a particular domain modeling decision will make or break a pricing tier, or that deferring a feature creates a dependency that blocks three other features in the next quarter.

That strategic reasoning — the ability to see the future implications of present decisions — is what the human brings. And it's not reducible to a prompt.

The methodology I've described is labor-intensive on the front end. You can't skip the compliance layer, shortcut the adversarial convergence, or hand-wave the closed story boundaries. Each layer produces the inputs the next layer requires, and the traceability between layers is what makes the whole chain auditable — which matters in regulated environments, but also matters in any environment where you want to understand why a decision was made six months from now.

The pattern is transferable. I've run it across three products in different domains, with different tech stacks, different team sizes, and different regulatory requirements. The 40% correction rate without the framework is consistent. The 95% accuracy with it is consistent. The methodology scales because the problem it solves — ambiguity at execution time — is universal.

The Human Role Didn't Shrink. It Clarified.

The job of humans in this era has changed. We are no longer responsible for the mundane, repetitive tasks that AI handles better and faster. What we own is design and vision.

My role shifted entirely to where it has the highest leverage: making decisions during planning, setting architectural direction during domain convergence, and reviewing delivery for intent preservation. I'm not reviewing less. I'm reviewing differently. Instead of reading every line of code to find defects, I'm looking at the shape of what's delivered, confirming it matches the specification, and trusting the CI pipeline to enforce the details mechanically.

The AI is a better executor than it is a decision-maker. The methodology I've built accepts that constraint and designs around it. Every decision gets made by a human with domain context, documented with traceability, and locked before execution begins. The AI then does what it's actually good at: translating explicit instructions into consistent output at speed. And the CI pipeline validates every translation, every time, without human intervention.

That's the unlock. Not better AI. Better inputs to AI — created by humans who understand what they're building and why it matters.

Introducing Moment and Facet: Your Domain Model Deserves to Run Before Your Code Does

Sun, 05 Apr 2026 00:03:30 GMT

You changed a field. Three downstream services broke in production. Nobody saw it coming — not the type checker, not the tests, not the code review. The contract between your service and theirs was never written down, never tested, and never visible to anyone. It lived in tribal knowledge and hope. And it broke on a Tuesday.

If you've built distributed systems, you have a version of this story. Maybe it was a renamed event field. Maybe it was a new required property that one consumer expected and another didn't. Maybe it was a multi-step process that spanned three services and silently stopped completing because the second one changed its response shape. The details differ. The shape is always the same: the failure lived in the space between services, where nobody was looking.

I've been building software for over twenty years — Fortune 500 companies, startups that didn't survive, solo consulting where the architecture lived entirely in my head. Across all of that, this is the failure mode that never goes away. Not because engineers are careless. Because there's no tool that makes the contracts between services visible, testable, and enforceable before you ship.

I've spent the last year writing about this gap. I named patterns. I documented a methodology. I wrote about what happens when you use AI not for code generation, but for domain modeling — the hard, slow, unglamorous work of deciding what your system means before deciding how it runs.

What I didn't write about is that I was building the thing I couldn't find.

Today I'm releasing Moment — an open-source domain specification toolchain — and Facet, its companion visualization platform.

The gap that nobody names

Here's the thing about Domain-Driven Design that nobody talks about at conferences: there's no specification layer.

You whiteboard it. You sticky-note it. You argue about bounded context boundaries in a room (or alone, staring at a screen). And then you go write code. There's nothing in between. No artifact that says "this is the model" in a way that generates your types, your tests, your documentation, and your API contracts. No way to ask "does this event flow actually work?" before you've implemented both sides.

Your domain model lives in seven places by the end of week one: the wiki page that's already stale, the TypeScript interfaces that diverged on Tuesday, the tests that test the wrong contract, the Markdown doc nobody reads, the API spec that's three fields behind, the whiteboard photo from last sprint, and someone's head.

Six of those will be wrong by next month. You just won't know which six.

Evans gave us the vocabulary for where things live — bounded contexts, aggregates, entities, value objects. That spatial model changed everything about how we think about software. But the vocabulary for how things move through time — events crossing boundaries, processes orchestrating across contexts, policies reacting to state changes — has no formal home. It lives in conversations that ended months ago and assumptions nobody wrote down.

That's the gap. And it's where every painful production incident I've ever debugged actually lived.

Two tools. One workflow.

Moment lives in your terminal. Facet lives in your browser. Together they do something that doesn't exist anywhere else in the DDD ecosystem: they let you run your domain model before you write implementation code.

Moment is a specification language and toolchain. You write a .moment file — one file — that describes your bounded contexts, aggregates, commands, events, and the temporal flows between them. Flows are the key. A flow describes events crossing bounded context boundaries with explicit relationship types and contracts. OrderPlaced crosses from Ordering to Fulfillment via CustomerSupplier, and the contract says orderId and items are required. That crossing has never had a home before. Now it does.

From that one file, Moment generates everything downstream: typed TypeScript interfaces, BDD scenarios, test scaffolds with crossing assertions, specification documents with Mermaid diagrams, and AsyncAPI 3.0 contracts. One specification, six artifact types, zero drift. Deterministic output — same input, same output, clean git diffs.

But generation isn't the revelation. Simulation is.

Facet is where your domain model becomes visible. Run moment simulate and Moment produces synthetic event flows — complete with causation chains, correlation tracking, and branch paths. Open Facet and you see those flows rendered as interactive timelines. You watch OrderPlaced cross from Ordering to Fulfillment. You see the causation chain — which event caused which. You see where a contract field is missing, where a process stalls, where a branch path leads somewhere your model didn't anticipate.

You see your domain model running. Before a single aggregate class exists.

I can't overstate what this felt like the first time it worked. I'd spent months writing specifications, generating code, trusting that the model was right because the types compiled and the tests passed. Then I opened Facet and watched the events flow through the system I'd described — and I could see the places where my thinking was incomplete. Not wrong, exactly. Incomplete. Assumptions I'd made about how contexts interact that I'd never been forced to make explicit.

In every other engineering discipline, you test the design before you build. Civil engineers don't pour concrete and then check load calculations. Chip designers don't fabricate and then verify logic. But in domain modeling, we've been going from whiteboard to code for twenty years and pretending that's fine.

It's not fine. We just didn't have the tooling to do better.

What the specification looks like

A .moment file reads like a domain description, not a programming language:

context "Ordering" [Core]

  aggregate "Order"
    identity orderId: UUID

    command PlaceOrder
      input customerId: UUID, items: OrderItem[]
      precondition orderNotPlaced: "Order has not already been placed"
      emits OrderPlaced

    event OrderPlaced
      orderId: UUID
      customerId: UUID
      items: OrderItem[]
      placedAt: DateTime

flow "order-placed"
  lane ordering "Ordering" [Core]
  lane fulfillment "Fulfillment" [Supporting]

  moment "Order submission"
    ordering: PlaceOrder
    ordering: OrderPlaced crosses-to fulfillment via CustomerSupplier
      contract
        orderId: UUID [required]
        items: OrderItem[] [required]

The flow block is what makes this different from every DDD tool that's come before. It encodes the temporal dimension — the thing Evans didn't formalize, the thing Brandolini's sticky notes gesture at but can't enforce. The crossing contract that broke on a Tuesday? This is where it lives now.

I won't walk through the full pipeline here — the site has a seven-tab interactive example showing the generated TypeScript, Gherkin, test scaffolds, spec docs, AsyncAPI, and simulation output from a single .moment file. Go look. It's the thing I'm proudest of on that page.

Where this came from

I'm a solo founder. No team. No co-founder. Just me and an AI partner doing the kind of knowledge crunching that Evans described in 2003 — except instead of a room full of domain experts, it's one architect with twenty years of scar tissue and a language model that never forgets a bounded context boundary.

That practice produced Signal-Driven Development — a three-pass convergence methodology where you model, run a gap report, resolve gaps, and iterate until the gap count hits zero. Zero gaps is the definition of done that DDD never had. I wrote about it. I built the templates. I applied it to every product in my ecosystem, across hundreds of ADRs and thousands of domain decisions.

And through all of it, one realization kept growing: the spatial model isn't enough. DDD gives you a world-class vocabulary for structure — what lives where, what owns what, what depends on what. But it gives you almost nothing for motion — how events flow through that structure over time, what contracts govern the crossings, what happens when a process spans three contexts and the second one fails.

That's what Moment formalizes. And Facet makes it visible.

The ecosystem

Moment and Facet are part of a larger toolchain called Complai. The full workflow:

Sift discovers domains — bounded contexts, aggregates, commands, events — through AI-mediated knowledge crunching. It publishes structured domain events.

Moment takes those building blocks and adds temporal scope — flows, crossings, and contracts. It generates typed implementations and simulation scenarios.

Facet visualizes those scenarios — interactive timelines, causation chains, crossing contracts, branch paths. It's where you see your model run.

Forge (coming soon) bootstraps project structure from Moment's typed artifacts.

Every event flowing between these tools uses a shared envelope format. Each tool can be used independently — Moment doesn't require Sift, Facet doesn't require an account for local simulation. The full ecosystem page shows how they connect.

Current state

Moment is functionally complete. Ten packages published on npm under @mmmnt/*. The full pipeline works end-to-end: parse, derive, generate, emit. Schema governance, drift detection, simulation, MCP server — all shipped.

Facet is live at facet.mmmnt.dev.

Try it

git clone https://github.com/mmmnt/mmmnt.git
cd mmmnt && pnpm install && pnpm turbo build
moment parse spec.moment
moment derive
moment generate --all
moment simulate

Then open the simulation output in Facet and watch your domain model run.

Moment: moment.mmmnt.dev
Facet: facet.mmmnt.dev
GitHub: github.com/mmmnt/mmmnt
Discord: discord.gg/YcRqsQUQuu
SDD Methodology: sdd.mmmnt.dev

Moment stands on the shoulders of the DDD community — Evans, Young, Brandolini, Vernon, Tune, Khononov — and encodes their patterns into a toolchain that enforces what books can only recommend. And a thanks to Hatoum for NDD, and introducing me to DDD 11 years ago.

I built the thing I needed. I think you might need it too.

Event Storming Is a Language, Not a Workshop

Mon, 30 Mar 2026 03:37:15 GMT

The DDD community treats Event Storming as a workshop activity. You book a room. You buy sticky notes — orange for domain events, blue for commands, yellow for aggregates, purple for policies, pink for hotspots. You invite the domain experts, the developers, the product managers. You fill a wall. You photograph it. You translate it into Jira tickets and architecture diagrams. Then the sticky notes come down and the wall goes back to being a wall.

That's how Event Storming is taught, practiced, and discussed. As a facilitated session with a physical output that exists for as long as the adhesive holds.

I think this framing buries the most important thing Brandolini created. And I think the evidence shows that what he created is bigger than the workshop format can contain.

Start with the sticky note colors. They aren't a workshop convenience. They're a type system.

Orange means "something happened" — a domain event. Blue means "someone or something wants to cause a change" — a command. Yellow means "this thing owns state and enforces rules" — an aggregate. Purple means "when this happens, do that" — a policy. Pink means "we don't understand this yet" — a hotspot. Lilac means "this is derived data" — a read model.

Each color is a semantic classification. Each classification carries behavioral expectations. An orange sticky doesn't just label a fact — it declares that something irreversible occurred in the domain, that downstream consequences may follow, and that the system's state changed in a way that matters to the business. A purple sticky doesn't just describe a reaction — it declares a stateless causal link between an event and a command, a temporal dependency that governs how the system behaves over time.

These aren't categories you impose on a domain. They're structural roles that domain concepts naturally fill. Every domain has things that happen (events), things that cause change (commands), things that own state (aggregates), and things that react to change (policies). Brandolini didn't invent these roles. He gave them colors.

The question is whether the colors — the vocabulary — are bound to the workshop format, or whether they describe something about reactive systems that exists independently of sticky notes on a wall.

Here's the argument that they do.

Take any reactive domain and model how it behaves over time. Not what it is — what it does. Follow a single business process from trigger to completion.

A customer places an order. That's a domain event — something happened. The system needs to reserve inventory. That's a policy — when an order is placed, initiate reservation. The policy produces a command — ReserveInventory. The command executes against the Inventory aggregate, which checks stock levels, enforces the invariant that reserved quantity cannot exceed available quantity, and emits a new event — StockReserved. That event triggers another policy — when stock is reserved, initiate payment capture. Payment capture produces a command against the Payment aggregate. The Payment aggregate processes it and emits PaymentCaptured. Which triggers the fulfillment policy. Which produces the CreateShipment command. Which executes against the Shipment aggregate. Which emits ShipmentCreated.

Event → Policy → Command → Aggregate → Event → Policy → Command → Aggregate → Event.

Orange → Purple → Blue → Yellow → Orange → Purple → Blue → Yellow → Orange.

I didn't import Event Storming to produce that decomposition. I described what happens in the domain over time, and the vocabulary appeared. The events are events because irreversible things happened. The policies are policies because stateless reactions connect those events to actions. The commands are commands because something needs to change state. The aggregates are aggregates because something owns the state being changed and enforces the rules about how it changes.

The reactive flow isn't a framework. It's how temporal causality decomposes in bounded systems. Brandolini's colors are a notation for a structure that already exists in every reactive domain.

Now go further. Look at what happens at the boundaries.

The OrderPlaced event was emitted by the Order aggregate in the Order bounded context. But the InventoryReservation policy lives in the Inventory context. That event just crossed a context boundary. The policy that consumes it doesn't know anything about the Order aggregate's internals — it only knows that something happened and it needs to react.

This is where Evans' Anti-Corruption Layer meets Brandolini's reactive flow. The context boundary is the place where the event's semantics must be translated — where OrderPlaced in the Order context becomes a signal that the Inventory context interprets through its own ubiquitous language. The policy is the translation mechanism. It sits at the boundary, consumes a foreign event, and produces a command in the local context's vocabulary.

Brandolini's purple sticky — the policy — is doing the same work as Evans' ACL. It's the boundary translation layer for reactive flows. This isn't a metaphor. It's a structural equivalence. The policy sticky note is the temporal version of the spatial ACL. Evans described how bounded contexts protect their internal models from external semantics. Brandolini described how bounded contexts react to external events through local translations. Same architectural function, different dimension — space versus time.

Nobody in the DDD literature has formalized this equivalence. Evans writes about spatial boundaries. Brandolini writes about temporal flows. The two vocabularies coexist in the community without anyone pointing out that they're describing the same boundary mediation from different angles.

The shift that made this visible to me came from an unexpected place.

Narrative Driven Development — Sam's work — introduced a framing that reoriented how I think about domain events entirely. NDD treats domain events not as data payloads or state transitions, but as moments in time. A domain event isn't just a record that something changed. It's a moment with temporal significance — it happened at a point in time, in a sequence, with causal relationships to what came before and what comes after.

This sounds like a nuance. It isn't. It's a reorientation of the entire modeling perspective.

When you think of events as state changes, you model them as facts about aggregates. "The order's status changed to Placed." That's spatial — it describes the aggregate's state at a point. When you think of events as moments in time, you model them as points in a causal sequence. "An order was placed, which means inventory must be checked, which means payment must be captured, which means fulfillment must begin." That's temporal — it describes what unfolds across the system as a consequence.

The spatial framing keeps you inside the aggregate. The temporal framing pulls you across boundaries, through policies, into the reactive flow that connects the entire domain. And the moment you model with temporal scope — events crossing boundaries over time — Event Storming's swim lane vocabulary isn't something you choose to use. It's the structure your model produces.

NDD planted the seed. Months of building grew it into something I couldn't ignore: the reactive flow decomposition isn't Brandolini's invention. It's a property of temporal domain modeling that Brandolini's workshop makes visible. The workshop is one discovery mechanism. Temporal modeling is another. They converge on the same structure because the structure is in the domain, not in the method.

Here's where this gets practically important and stops being philosophical.

If Event Storming's vocabulary is a discovered structure rather than an invented method, then access to that structure doesn't require the workshop. This matters because the workshop has prerequisites that exclude a large part of the DDD community.

You need a room. You need domain experts who can dedicate half a day or more. You need a facilitator skilled enough to keep the session productive. You need developers and product people in the same physical or virtual space. You need the organizational authority to pull all of these people out of their day jobs simultaneously.

Solo practitioners don't have this. Small teams don't have this. Engineers at companies where domain experts are executives who won't sit in a four-hour workshop don't have this. The workshop format creates an accessibility barrier that locks out precisely the people who would benefit most from the vocabulary.

But the vocabulary works without the workshop. You can model a domain's temporal behavior alone — event by event, policy by policy, command by command — and arrive at the same reactive decomposition that a room full of sticky notes would produce. Not because you're doing Event Storming without the workshop. Because you're modeling temporal causality, and the structure is the same regardless of how you discover it.

The workshop is valuable. Brandolini's facilitation techniques surface domain knowledge from non-technical experts in ways that nothing else matches. The physical, collaborative, high-energy format produces insights that solo modeling rarely does. If you can run a workshop, run one.

But stop telling people that Event Storming requires the workshop. It doesn't. The workshop requires Event Storming's vocabulary. The vocabulary doesn't require the workshop. The distinction matters because thousands of practitioners are locked out of the method by logistics while the language sits there, available, waiting to be used.

There's a deeper point here about what Brandolini actually contributed to DDD.

Evans gave us the spatial vocabulary — bounded contexts, aggregates, entities, value objects. The nouns of domain modeling. The things the system is.

Brandolini gave us the temporal vocabulary — events, commands, policies, read models. The verbs of domain modeling. The things the system does.

These aren't competing frameworks. They're complementary dimensions of the same domain. Evans models the space. Brandolini models the time. Together, they give you a complete vocabulary for describing what a system is, what it does, how it reacts, and how it changes.

But the community treats Evans as the foundation and Brandolini as a workshop technique. That's wrong. Brandolini's vocabulary is as foundational as Evans'. It's just been trapped inside a workshop format that makes it look like a facilitation tool instead of what it actually is — the temporal half of domain-driven design.

Event Storming isn't a workshop. It's a language. The workshop is one way to speak it.

It's not the only way.

This is an independent post — not part of the Signal-Driven Development series. More at listenrightmeow.hashnode.dev

AI Made My Architecture Deeper, Not Simpler

Sun, 29 Mar 2026 23:40:25 GMT

The pitch is always simplification. AI will make development faster, architectures leaner, systems easier. Fewer decisions, fewer layers, fewer meetings. Point the model at your domain, let it generate the structure, ship it.

That's not what happened.

What happened is the opposite. Working with AI as a domain modeling partner over months of sustained architectural work produced a system with more layers, more explicit decisions, more structural depth than anything I've built with a team. Not because the AI over-engineered it. Because the AI never let me skip the parts that teams routinely skip.

Here's what I mean by "skip."

Every architect has done this: you're modeling a domain, you hit a decision that requires careful analysis, and you defer it. Not intentionally. You just move on because the next bounded context is more interesting, or the aggregate you're working on feels close enough, or the team is tired and somebody says "we'll clean this up later." The decision doesn't get made. It doesn't get documented. It becomes an implicit assumption embedded in the codebase, invisible until something breaks in production and someone traces the failure back to a modeling choice that was never actually a choice — it was an absence.

Teams do this constantly. Not because they're careless, but because collaborative modeling has natural momentum. Discussions move forward. Whiteboards get erased. The facilitator keeps the energy up. And the hard, awkward, slow decisions — the ones where you sit with ambiguity for twenty minutes before the right boundary reveals itself — those are exactly the decisions that group dynamics conspire to skip.

AI doesn't have group dynamics. It doesn't get tired of your domain model. It doesn't lose context from the session three weeks ago. And when you move past a decision without resolving it, it doesn't politely let it go. You can try to skip ahead, but the model holds. Every unresolved ambiguity sits there, waiting, until you deal with it.

That's not simplification. That's a forcing function for depth.

Two patterns emerged from this work that I didn't anticipate.

The first was the Candidate Lifecycle — the realization that when AI generates domain artifacts, every output must enter as a candidate, not as confirmed knowledge. In a team setting, the knowledge crunching process embeds trust implicitly. The domain expert says "we process refunds within 30 days," the team discusses it, the model absorbs it. Nobody stamps it "confirmed." The confirmation was the conversation itself.

AI doesn't participate in that conversation. It generates interpretations — some right, some close, some subtly wrong in ways that look right. Without an explicit confirmation boundary, those interpretations flow into the model as if they were validated domain knowledge. They weren't. They were candidates that nobody reviewed because the process assumed implicit trust that no longer existed.

I didn't design the Candidate Lifecycle because I read a paper about AI trust boundaries. I designed it because I watched interpretations enter the model unchallenged and realized the model was accumulating confident noise. The pattern wasn't planned. It was forced — the architecture demanded it because the alternative was a domain model built on unverified assumptions.

The second was the Classification Gap — the discovery that a semantically wrong but structurally valid classification produces a model that passes every check. A reactive behavior misclassified as a static constraint looks perfect on paper. The gap report says nothing. The heuristics are healthy. And the architecture is missing an entire reactive path because the concept that would have anchored it was placed in the wrong category.

I didn't discover the Classification Gap through a literature review. I discovered it because I was staring at a specification that looked clean but felt wrong. Something was missing from the event flows, but the gap report insisted the model was converged. Tracing it back led to a single concept — a Policy classified as an Invariant — that had silently collapsed a temporal behavior into a spatial constraint. Structurally valid. Semantically backwards. Invisible to every automated check.

Both of these patterns — the Candidate Lifecycle and the Classification Gap — are things a team would eventually discover too. In production. After the architecture hardens around the wrong assumptions. After the missing reactive path causes a failure that nobody can trace to a modeling decision because the decision was never visible in the first place.

AI surfaced them during modeling. Not after deployment. Not during code review. During the part of the process where they were still cheap to fix.

This is the counterintuitive result: AI partnership doesn't produce simpler architectures. It produces more honest ones.

Every decision that a team would have deferred, the AI partnership forced. Every ambiguity that would have been papered over with "we'll figure it out during implementation," the modeling process surfaced and demanded resolution. Every classification that would have gone unchallenged because the team was moving fast and the model looked clean enough — each one became a decision point with explicit confirmation or rejection.

The architecture got deeper because every layer exists for a reason that was articulated during design, not discovered during debugging. The provenance chains exist because I realized AI interpretations needed auditable lineage. The confirmation boundaries exist because I watched unverified outputs accumulate. The classification verification exists because I found the invisible error that passes every test.

None of these layers were planned in advance. None of them came from an architecture diagram drawn before writing code. They emerged from the sustained pressure of building with a partner that has perfect recall, infinite patience, and no incentive to skip the hard parts.

I want to be precise about what I'm not saying.

I'm not saying AI is a better collaborator than humans. A domain expert who knows the business deeply, who can say "no, that's not how we process claims" with the authority of ten years of operational experience — that person is irreplaceable. AI doesn't have domain expertise. It has pattern recognition and recall.

I'm not saying teams produce shallow architectures. Teams with strong architects, good facilitation, and genuine domain expert participation produce extraordinary systems. The best architectures I've seen were built by teams, not solo practitioners.

What I'm saying is that the specific mechanics of sustained AI partnership produce architectural depth in places that other processes don't reach. Let me be concrete about why.

A human collaborator holds maybe three or four bounded contexts in their head at once. By the fifth, they're referencing notes from earlier sessions, reconstructing context, losing the fine-grained relationships between aggregates in Context A and the policies they trigger in Context C. That's not a criticism — it's a cognitive limit. AI holds the entire specification in working memory. All six bounded contexts, all nine aggregates, all fifty-four domain events, all the invariant relationships between them, simultaneously. When you say "does this new policy in the Order context conflict with the fulfillment saga we defined three weeks ago," the answer comes back with the specific saga steps, the events it subscribes to, and the exact point where the new policy would create a race condition. No notes. No reconstruction. Immediate structural reasoning across the full model.

That changes what questions you can ask. You stop simplifying your questions to fit your collaborator's context window and start asking the hard cross-cutting questions that would take a team twenty minutes of whiteboard reconstruction. The architecture gets deeper because the questions get harder.

Then there's adversarial reasoning. I can ask my AI collaborator to argue against its own recommendation. Not as a performance — genuinely. "You just suggested this aggregate boundary. Now tell me why it's wrong. What would Vernon say? Where does this violate the heuristic thresholds we set in the last pass?" And the challenge comes back with structural reasoning, not ego. No defensiveness. No anchoring to its own prior suggestion. It will tear down something it built ten minutes ago if the reasoning demands it. Try asking a human architect to genuinely attack their own design decision in the same session they made it. The social dynamics make it almost impossible. The AI has no social dynamics. The adversarial review is clean.

There's the forcing function of articulation. You cannot hand-wave past a decision with an AI partner. With a team, you can say "this aggregate handles order state" and everyone nods because they roughly know what you mean. With AI, that statement generates follow-up: which state transitions? What commands mutate it? What invariants constrain those transitions? What events are emitted? If you can't answer, the model has a gap, and the gap is visible immediately — not six weeks later when someone tries to implement it and discovers the aggregate's responsibilities were never actually defined.

And there's the absence of sunk cost. Human teams invest identity in architectural decisions. The person who championed the microservice boundary feels ownership of it. Challenging it three months later isn't just a technical discussion — it's a social one. AI has zero investment in prior decisions. When the third pass reveals that a boundary drawn in the first pass was wrong, the restructuring is purely analytical. No politics. No hurt feelings. No "but we already built the infrastructure for this." The architecture evolves based on what the domain demands, not what the team has already committed to.

None of this replaces the domain expert. None of it replaces the team that debates trade-offs over lunch and builds shared understanding through years of working together. Those things produce their own kind of depth — the kind that comes from lived operational experience and collective intuition.

But this combination — one architect, full model context, adversarial reasoning without ego, forced articulation, zero sunk cost — changed how I will architect for the rest of my career. Not because AI is smarter than the teams I've worked with. Because it operates in a fundamentally different mode that reaches places those teams structurally couldn't, for reasons that have nothing to do with intelligence and everything to do with mechanics.

The complexity wasn't added. It was always in the domain, waiting for a process that wouldn't let me look away.

Next: If AI introduces failure modes that structural analysis can't catch and trust boundaries that traditional DDD never needed, what's the architectural response? The same one Evans gave us for legacy systems — but applied to intelligence instead of data.

This is Post 8 of a 17-post series on Signal-Driven Development — a solo-practitioner DDD methodology built with AI. Post 7: The Classification Gap

The Classification Gap: The Bug That Passes Every Test

Sun, 29 Mar 2026 22:47:38 GMT

There's a class of domain modeling error that no test catches. No structural analysis flags it. No linter complains. Your gap report comes back clean. Your aggregate has the right number of invariants, your bounded context has healthy ratios, your event flows trace end to end.

The model is wrong.

Not wrong like a missing field or a misspelled event name. Wrong like a reactive behavior modeled as a static constraint. Wrong like a Policy collapsed into an Invariant — structurally valid, semantically backwards, invisible to every check you run against it.

I call this the Classification Gap. And if you're using AI to assist with domain modeling — even informally, even just bouncing ideas off ChatGPT — you will hit it. You probably already have. You just couldn't name it.

Here's the example that made it concrete for me.

An architect describes a business rule: "When an order is placed, check inventory and reserve stock." That's a reactive behavior. Something happens — an order is placed. In response, the system does something — checks inventory, reserves stock. In DDD vocabulary, this is a Policy. A stateless reaction to a domain event that produces a downstream command. The triggering event and the resulting action are the whole point.

Now imagine the AI classifies it as an Invariant instead. An Invariant is a static constraint on an aggregate — a rule that must always be true. "An order cannot exceed the customer's credit limit." "A shipment must have at least one line item." These are structural truths about the domain. They don't react to events. They don't trigger commands. They just... hold.

The misclassification looks fine. The Invariant has a name, a description, an owning aggregate. The aggregate now has one more invariant — which actually improves its invariant-to-command ratio. If you're running structural completeness checks, every box is ticked. If you're evaluating heuristic thresholds, the numbers look healthier than before.

The gap report says nothing.

But you've just collapsed a temporal behavior into a spatial constraint. You've taken something that fires when an event crosses a boundary and turned it into something that sits inside an aggregate doing nothing. The reactive path — the entire causal chain from "order placed" to "stock reserved" — is gone from the model. Not broken. Not misconfigured. Just absent, because the concept that would have anchored it was placed in the wrong category.

In traditional DDD, this mistake is self-correcting. A human modeler who classifies a reactive behavior as a static constraint will feel the friction at implementation time. They'll try to write the code and something won't fit. The Invariant doesn't express what they meant. The code becomes awkward. The feedback loop is the implementation itself — the discomfort of writing code that fights the model is the signal that the model is wrong.

Evans never had to name this problem because the modeling medium — human conversation, whiteboard sessions, iterative refinement through code — naturally surfaces it. The human modeler carries the semantic intent in their head. When the model diverges from that intent, they feel it. They may not articulate it as "I misclassified a Policy as an Invariant," but they'll say "this doesn't feel right" and restructure.

AI doesn't feel anything.

When an AI classifies a concept into a building block type, it commits with confidence. The classification is linguistically coherent. The output is well-structured. And the moment it enters your domain model, the original semantic intent — the reactive behavior, the temporal causality, the "when X happens, do Y" — is gone. What remains is a structurally valid Invariant with no trace of what it was supposed to be.

The feedback loop is broken. Not degraded, not delayed — broken. Because every downstream check evaluates the classified output, not the original intent. Structural analysis sees a valid Invariant. Heuristic evaluation sees healthy ratios. The gap report confirms convergence. The system has produced an internally consistent model built on a wrong foundation, and nothing in the verification pipeline can see it.

This is what makes the Classification Gap different from every other modeling error. Missing elements get caught by structural completeness checks. Threshold violations get caught by heuristic analysis. Naming inconsistencies get caught by convention rules. Every other category of error leaves a visible trace — a gap in the report, a metric outside bounds, a rule that fires.

The Classification Gap leaves no trace because the model is complete. The error isn't in what's missing. It's in what's present but miscategorized.

And the most susceptible boundary — Policy versus Invariant — is also the most architecturally consequential. It's the boundary between time and space in your domain model. Between something that reacts to events and something that constrains state. Get it wrong and you don't just have a cosmetic error in your specification. You have a model that will produce an architecture without the reactive paths your domain requires. The event flows won't be designed because the concepts that anchor them were never modeled as reactive. The sagas won't be triggered because the policies that initiate them don't exist.

The system will work. It will pass tests. And it will be fundamentally wrong about how the domain behaves over time.

This isn't just a Policy-versus-Invariant problem, though that's the sharpest edge. Every classification boundary in DDD carries some version of this risk.

A Command misclassified as a Domain Event inverts the causal direction — intentions become facts, and the model's sense of what requests action versus what records completion flips. An Aggregate misclassified as a Domain Service loses its state boundary — the invariant enforcement surface disappears, and the consistency guarantee with it. A Policy over-promoted to a Saga gains compensation logic it doesn't need, adding architectural complexity for behavior that should be fire-and-forget.

Each of these is structurally valid. Each passes every check. Each produces a different architecture than the domain actually requires.

The common thread is that building block type is a semantic decision, not a structural one. It encodes what a concept does in the domain — how it relates to events, state, time, and causality. Structural analysis can verify that the pieces fit together. It cannot verify that the pieces are the right kind.

If you're using AI for domain modeling today — even as a thinking partner, even just for brainstorming bounded contexts or sketching event flows — the Classification Gap is already in your process. The question isn't whether it will happen. The question is whether you'll catch it before the architecture hardens around it.

Traditional DDD never needed a name for this because the detection mechanism was embedded in the human modeler's discomfort. AI-mediated DDD needs the name because the discomfort doesn't exist. The model looks clean. The verification passes. The architecture proceeds.

And somewhere in your specification, a behavior that should react to events is sitting quietly as a constraint, waiting for someone to notice that the system doesn't do what the domain requires.

That's the Classification Gap. The bug that passes every test.

Next: The architecture that emerged from building detection for problems like this was deeper than anything a team would have produced. Not because AI is smarter — but because it doesn't let you skip the hard parts.

This is Post 7 of a 17-post series on Signal-Driven Development — a solo-practitioner DDD methodology built with AI. Post 6: The Candidate Lifecycle

When Jobs to Be Done Meets Domain-Driven Design

Sun, 22 Mar 2026 05:31:42 GMT

There are moments in practice where two ideas you've held separately for years suddenly click together — not because someone told you they were connected, but because you were working through a problem and the structure fell out on its own.

This happened to me recently while thinking through how user input normalizes into domain concepts. I was working with the Jobs to Be Done framework on one side and Domain-Driven Design building blocks on the other. And the mapping wasn't just convenient. It was nearly exact.

What surprised me more: nobody seems to have published this connection.

Two Frameworks, Same Year, Same Problem

Clayton Christensen popularized Jobs to Be Done in The Innovator's Solution in 2003. The core idea: customers don't buy products — they hire them to do a job. Understanding the job — the situation that triggers the need, the motivation behind the action, the outcome that signals completion — is the only reliable way to understand what to build.

Eric Evans published Domain-Driven Design: Tackling Complexity in the Heart of Software in 2003. Same year. His core idea: software should model the domain — not the database, not the UI, not the org chart. The domain model is the shared language between engineers and domain experts. Get the model right, and the system writes itself. Get the model wrong, and no amount of engineering fixes it.

Two books. Same year. Completely different audiences — product people reading Christensen, architects reading Evans. They decomposed the same fundamental question: what should this system do, and why?

They never cited each other.

The Mapping

A JTBD statement has a canonical structure:

"When I [situation], I want to [motivation], so I can [outcome]."

That structure isn't decorative — it's a decomposition. And each component maps directly to a DDD building block:

JTBD Component	What It Captures	DDD Building Block
Situation ("When I...")	The state of the world that triggers the need	Context / Preconditions
Motivation ("I want to...")	The action the actor wants the system to perform	Commands / Intents
Outcome ("So I can...")	The observable result that satisfies the job	Domain Events / Post-conditions

Read that table again. A product manager who writes "When a compliance violation occurs, I want to be notified immediately, so I can remediate before audit" has already decomposed three things:

A domain event that triggers behavior (violation occurred)
A command that expresses intent (notify me)
A post-condition that defines success (remediation triggered before audit)

They don't know they've done it. They've never heard the term "aggregate root." But the decomposition is structurally identical to what an architect would produce in an Event Storming session.

What the Mapping Means

This isn't a party trick. The structural alignment has three real consequences.

First, JTBD input normalizes directly into DDD concepts. If you take a well-formed JTBD statement and decompose it — situation into context, motivation into command, outcome into event — you get the raw material for a domain model. No interpretation layer required. The structure does the translation.

Second, DDD gives JTBD structural rigor. JTBD practitioners struggle with vague outcomes. "So I can feel confident" is a common pattern — and it's useless for both product and engineering. DDD's requirement for observable state changes forces outcomes to be concrete. Not feelings — events. Not aspirations — post-conditions. If the outcome can't be modeled as something that happened in the system, the JTBD statement is incomplete.

Third, the gap between product and engineering shrinks. If JTBD input maps to DDD building blocks, then the translation layer between "what the user needs" and "what the system models" becomes mechanical, not interpretive. The architect doesn't have to guess what the product manager meant. The product manager doesn't have to understand aggregates. The decomposition structure itself bridges the vocabulary gap.

This is the part that excites me most. The perennial friction between product and engineering isn't a people problem — it's a structural problem. Product teams and engineering teams decompose the same domain using different vocabularies. The JTBD-to-DDD mapping reveals that the vocabularies are isomorphic. They're describing the same structure with different words.

The Event Storming Parallel

The mapping gets more interesting when you bring in Alberto Brandolini's Event Storming.

Event Storming uses a specific flow: a domain event (orange sticky) triggers a policy or reaction, which issues a command (blue sticky), which produces a new domain event (orange sticky). The canonical reactive loop:

Event → Policy → Command → Event

Now look at the JTBD structure again:

Situation (something happened) → Motivation (I want to do something) → Outcome (something new happens)

And the DDD mapping:

Precondition (system state) → Command (intent) → Domain Event (state change)

Three independent frameworks. Three different disciplines — product management, domain modeling, collaborative workshop facilitation. Developed across a decade (2003, 2003, ~2013). And the decomposition shape is the same:

Trigger → Action → Observable Result.

The Shape of the Problem

Here's the thesis I keep coming back to.

When independent frameworks converge on the same structure without ever referencing each other, the structure isn't a framework artifact — it's a property of the problem domain itself.

Christensen wasn't thinking about domain events when he formalized the Situation → Motivation → Outcome structure. Evans wasn't thinking about jobs to be done when he modeled Precondition → Command → Event. Brandolini wasn't thinking about either when he laid out Event → Policy → Command → Event on a wall of sticky notes.

They were all trying to answer the same question: how do you rigorously decompose what a system should do and why? And they all arrived at the same shape.

That shape — trigger, action, observable result — isn't Christensen's invention, or Evans's, or Brandolini's. It's the shape of the problem. Every rigorous decomposition method finds it, because it's the only shape that captures causality, intent, and outcome in a single structure.

I've seen this convergence pattern before. When you model a domain with temporal scope — events crossing bounded contexts over time — Event Storming's swim-lane vocabulary emerges naturally as a byproduct. You don't set out to build Event Storming. You include temporal scope in the design, and the reactive flow (event → policy → command → event) organizes itself into the same vocabulary Brandolini formalized. You don't find Event Storming. Event Storming finds you — the moment you model events crossing boundaries over time.

The JTBD mapping is the same phenomenon one layer up. You don't set out to connect JTBD to DDD. You try to normalize user input into domain concepts, and the decomposition maps itself.

What This Means for Practice

If you're a product manager writing JTBD statements, you're already doing domain decomposition. You just don't have the vocabulary to name what you've produced. Learn enough DDD to recognize that your "outcomes" are domain events. It will make your JTBD statements sharper and your conversations with engineering more productive.

If you're an architect practicing DDD, look at the JTBD statements your product team is writing. They're not requirements — they're decompositions. The situation is your precondition. The motivation is your command. The outcome is your event. You may find that the product team has already done half your Event Storming before the session starts.

If you're a solo builder wearing both hats, this mapping is a gift. Write your own JTBD statements for the domain you're modeling. Then decompose them. Situation into context. Motivation into command. Outcome into event. You'll have the skeleton of a domain model before you draw a single diagram.

And if you're skeptical — try it. Take any well-formed JTBD statement and apply the mapping. See if the DDD building blocks fall out. In every case I've tested, they do. Not because the mapping is clever, but because the problem has a shape, and both frameworks found it.

Christensen and Evans published in the same year. They decomposed the same problem. They never cited each other. And the mapping is nearly exact.

Every JTBD statement is a domain event waiting to be named.

Further reading:

Clayton Christensen & Michael Raynor, The Innovator's Solution (2003)
Eric Evans, Domain-Driven Design: Tackling Complexity in the Heart of Software (2003)
Alberto Brandolini, Introducing EventStorming (~2013; eventstorming.com)
narrativedriven.org — Narrative-Driven Development, temporal modeling, and the reactive path vocabulary

The Candidate Lifecycle: When AI Models Your Domain, Who Confirms It?

Sun, 22 Mar 2026 05:17:18 GMT

This post marks a shift.

Posts 1 through 5 gave away a methodology — Signal-Driven Development, the gap report, the three-pass convergence process. That was the community gift. Use it, fork it, adapt it.

What follows is different. Over the next four posts, I'm formalizing patterns that emerged from practicing SDD rigorously with an AI collaborator across production domains. These aren't theoretical observations. They're problems I hit, named, and solved — problems that every team incorporating AI into domain modeling will encounter.

Nobody in the DDD community is publishing on these patterns, because nobody else has built a system that does AI-mediated domain modeling at this depth. That's not a boast. It's an observation about where the field is. Evans is writing about integrating AI components into deterministic systems. DDD Europe 2026 has workshops on LLM-assisted strategic design. The community is exploring the intersection. I've been living in it for months.

The first pattern is the Candidate Lifecycle. It answers a question that traditional DDD never needed to ask.

The Implicit Consensus Problem

In traditional DDD, knowledge crunching is collaborative. A group of people — developers, domain experts, architects — sit in a room, put stickies on a wall, argue about language, and iterate toward a model. The model that survives the room is the model the team has agreed on.

The agreement is implicit. Nobody votes on whether OrderPlaced is the right event name. Nobody signs off on the aggregate boundary. The team converged through conversation, and the model reflects that convergence. When the developer writes code that mirrors the model, they're implementing a shared understanding — imperfect, informal, but collectively owned.

This works because the feedback loop is human. When a domain expert says "that's not how we think about it," the model changes. When a developer says "I can't implement this boundary cleanly," the team revisits. The model is continuously validated by the people who created it.

Now replace the room with an AI.

You feed a product requirements document into a language model. The model produces a domain specification — bounded contexts, aggregates, events, commands, invariants. The specification is structurally plausible. The names sound right. The boundaries look reasonable. The event flows make sense.

But who agreed to this model?

The AI doesn't have domain expertise. It has statistical pattern completion trained on millions of documents that include DDD examples, software architecture discussions, and domain modeling content. When it names an aggregate OrderFulfillment and places it in a Logistics bounded context, it's not making a domain judgment. It's producing a statistically likely output given the input and its training distribution.

The model might be right. It might be excellent. But the mechanism that produced it is fundamentally different from the mechanism that produces a model in a collaborative workshop. There was no implicit consensus. There was no domain expert pushback. There was no developer saying "this boundary feels wrong." There was a prompt, a completion, and a plausible-looking output.

This is the implicit consensus problem: traditional DDD's trust model breaks when AI generates the domain model. The trust was always embedded in the process — we trust the model because we built it together. When AI builds it, that embedded trust doesn't exist.

The Candidate Lifecycle

The Candidate Lifecycle is a design pattern for AI-mediated domain modeling. It establishes an explicit trust boundary between AI-generated output and confirmed domain knowledge.

The core principle: nothing an AI produces is domain knowledge until an architect explicitly confirms it.

Every domain artifact that an AI generates — every aggregate, every event, every bounded context boundary, every invariant — enters the system as a candidate. A candidate is a proposal with provenance. It carries what was proposed, why it was proposed (the AI's reasoning), what alternatives were considered, and what produced it (which model, which prompt strategy, which input).

A candidate is not part of the domain model. It's a proposal to the domain model. The domain model only changes when the architect does one of three things:

Confirm: The candidate is correct. The AI's classification matches the architect's domain understanding. The aggregate should exist, the boundary is right, the event name is appropriate. The candidate becomes confirmed domain knowledge.

Override: The candidate is partially correct but misclassified. The AI identified a real domain concept but categorized it wrong — it proposed an invariant where the architect recognizes a policy, or it placed a service in the wrong bounded context. The architect corrects the classification while preserving the underlying insight. The override is recorded with rationale.

Reject: The candidate is wrong. The AI hallucinated a concept, misinterpreted the input, or produced something that contradicts the architect's domain understanding. The rejection is recorded with rationale — because the rejection is itself domain knowledge. It documents what the domain is not.

The confirmation, override, and rejection are the new design surface. In traditional DDD, the design surface is the whiteboard — where you draw boundaries and name things. In AI-mediated DDD, the design surface is the confirmation boundary — where you decide which AI proposals become trusted domain knowledge and which don't.

Why Provenance Matters

Every candidate must carry provenance — metadata about what produced it and why. This isn't an implementation detail. It's a domain requirement.

Provenance answers the question that every architect will eventually ask: "Why does this aggregate exist?" In traditional DDD, the answer is "we decided in the March workshop." In AI-mediated DDD, the answer must be traceable: this aggregate was proposed by this model version, using this prompt strategy, in response to this input, with this reasoning, and it was confirmed by this architect on this date.

Provenance serves three purposes.

Auditability: When a domain model is the foundation for a production system, someone will eventually need to reconstruct why a particular decision was made. Provenance provides the full chain — from the input document, through the AI's interpretation, to the candidate proposal, through the architect's confirmation. Every link in the chain is recorded.

Reproducibility: When you update your AI model or change your prompt strategy, you need to understand what changed. Provenance lets you ask: "Which candidates in this specification were produced by the previous model version? Have any of them been invalidated by the updated model's output?" Without provenance, model upgrades are blind — you can't tell which parts of your domain model might be affected.

Trust calibration: Over time, provenance data reveals patterns about AI reliability. Which types of domain concepts does the model classify well? Where does it consistently struggle? Provenance transforms individual confirmation decisions into aggregate insight about the AI's modeling capability. This is how the trust boundary becomes data-driven rather than faith-based.

The Evans Connection

At Explore DDD 2024, Evans framed a trained LLM on a ubiquitous language as effectively a bounded context. It has its own model of the domain, shaped by its training data and fine-tuning. It speaks a language that overlaps with but isn't identical to the domain expert's language.

This is a powerful framing. And the Candidate Lifecycle is the answer to the question it raises: how does knowledge from the AI's bounded context become trusted domain knowledge in the architect's model?

In traditional DDD context mapping, we have patterns for this. When two bounded contexts need to share knowledge, we use patterns like Published Language, Anti-Corruption Layer, Customer-Supplier, or Conformist. Each pattern defines who owns the translation, who controls the contract, and how mismatches are handled.

The AI's "bounded context" needs the same treatment. The AI produces output in its own model. That output must cross a trust boundary before it enters the architect's domain model. The Candidate Lifecycle is the translation mechanism — it's the Anti-Corruption Layer between the AI's statistical model and the architect's domain model.

Evans is now writing explicitly about this pattern — drawing Anti-Corruption Layers between deterministic application code and probabilistic LLM output. We arrived at the same architectural conclusion independently. The AI's output must be constrained, translated, and explicitly accepted before it enters the deterministic system. The Candidate Lifecycle formalizes the acceptance mechanism for domain modeling specifically.

What This Changes About DDD Practice

The Candidate Lifecycle has implications that go beyond the obvious.

The architect's role changes. In traditional DDD, the architect is a creator — they model the domain through collaborative discovery. In AI-mediated DDD, the architect becomes a curator and a judge. The AI generates candidates at a speed and volume that no human modeler could match. The architect's job is to evaluate, confirm, override, reject, and document. The creative act shifts from "invent the model" to "validate the model and improve it."

This isn't a lesser role. It's a more rigorous one. The architect who evaluates fifty AI-proposed candidates and confirms thirty, overrides twelve, and rejects eight has made fifty explicit domain decisions — each documented with rationale. The architect who draws a model on a whiteboard has made the same decisions implicitly, with no record of what was considered and rejected.

Rejection becomes a first-class artifact. In traditional DDD, rejected ideas are lost — they exist only in the memory of the people who were in the room. In the Candidate Lifecycle, every rejection is recorded with rationale. "This was proposed as an aggregate, but it has no invariants and no independent lifecycle — it's a value object" is domain knowledge. It documents what the domain is not, which constrains future modeling decisions and prevents the same mistake from being proposed again.

The speed of iteration changes. A three-pass convergence that might take weeks with a human team can happen in hours with AI generating candidates and an architect curating them. But the curation can't be automated — that's the whole point. The AI proposes, the architect decides. The speed gain is in generation, not in judgment.

Provenance creates institutional memory. When the architect who confirmed a set of candidates leaves the team, the provenance chain remains. The next architect can reconstruct not just what was decided, but why — including the AI's reasoning, the alternatives that were considered, and the rationale for each confirmation and rejection. This is better institutional memory than most teams have ever had for their domain models, because it was captured at decision time rather than reconstructed after the fact.

The Pattern in Practice

If you're incorporating AI into your domain modeling process today — whether through ChatGPT, Claude, a fine-tuned model, or a purpose-built system — here's how to apply the Candidate Lifecycle manually:

Mark everything the AI produces as provisional. Don't copy AI-generated domain concepts directly into your specification. Create a separate "candidates" section. Each candidate gets an ID, the AI's proposed classification (aggregate, event, policy, etc.), the AI's reasoning if available, and a status: pending, confirmed, overridden, or rejected.

Review candidates in bounded context order. Start with context boundaries. Then aggregates within each context. Then events and commands within each aggregate. Confirmation cascades downward — confirming a bounded context doesn't confirm its aggregates, but rejecting a bounded context rejects everything inside it.

Document every override and rejection. The override rationale ("this was proposed as an invariant but it's actually a policy — it reacts to events rather than constraining state") is more valuable than the confirmation rationale. Overrides and rejections are where your domain understanding diverges from the AI's pattern matching. They're the signal.

Track which model version produced which candidates. When you update your AI model or change your prompting approach, you need to know which parts of your domain specification were produced under the previous configuration. Provenance doesn't need to be sophisticated — "GPT-4o, March 2026, prompt v2" is sufficient for manual tracking.

Run the gap report after confirmation. The gap report (Post 5) evaluates the confirmed specification, not the raw AI output. Gaps found post-confirmation are real gaps in the architect's curated model — not noise from unreviewed AI proposals.

What Comes Next

The Candidate Lifecycle establishes the trust boundary. But it assumes the candidates are at least structurally valid — that an aggregate is an aggregate, that a policy is a policy, that the AI's classification is correct even if the domain judgment is wrong.

What happens when the classification itself is wrong? When the AI proposes something that passes every structural check, looks correct in every gap report, and produces a domain model that appears complete — but the behavioral semantics are fundamentally broken?

That's the Classification Gap. Post 7.

This is Post 6 of a series on DDD, AI, and the methodology that emerged from practicing both rigorously. Post 5 delivered the gap report deep dive and the SDD repository. The series continues with the Classification Gap in Post 7.

The Gap Report: DDD's Missing Feedback Loop

Sun, 22 Mar 2026 05:03:38 GMT

In Post 4, I introduced Signal-Driven Development and its core claim: DDD has never had a definition of done. SDD provides one — zero unresolved gaps across a structured convergence process.

But I left the gap report itself as a concept. This post makes it concrete. What does a gap report actually look like? What does it measure? How does the three-pass convergence trajectory work when you're sitting in front of a real domain specification?

I'm also releasing the SDD repository — templates for gap reports, resolution logs, domain specifications, and architecture palettes, plus a complete worked example showing three-pass convergence on a fictional domain. Grab the templates and run a pass on your own system. That's not a suggestion — it's the fastest way to understand whether SDD solves a problem you have.

Anatomy of a Gap Report

A gap report evaluates a domain specification against four categories. Each gap is a question the specification hasn't answered.

Structural Gaps (SG) are missing or malformed elements. These are binary — the element exists or it doesn't. An aggregate without invariants. A command that doesn't produce a domain event. A bounded context with no declared relationships to other contexts.

Structural gaps are the easiest to identify and the most dangerous to ignore. An aggregate without invariants is a consistency boundary that enforces nothing — it's a data structure with a misleading name. Evans is explicit about this: the aggregate exists to protect invariants. If there are no invariants, there is no aggregate.

Heuristic Gaps (HG) are patterns that violate established DDD principles. Unlike structural gaps, these aren't binary — they're threshold-based. Vernon's small aggregate heuristic suggests no more than six commands per aggregate. Evans's bounded context principles suggest no more than three shared terms across contexts before you question whether the boundary is real. Saga step counts beyond five suggest decomposition.

Every heuristic has a measurable default grounded in published DDD literature. Every default is overridable — because every domain has legitimate reasons to deviate. The gap report doesn't penalize deviation. It forces you to acknowledge and document it. The difference between an architect who exceeds a heuristic intentionally and one who exceeds it accidentally is the documentation of the decision.

Language Gaps (LG) are ambiguities in the ubiquitous language. The same term used with different meanings across contexts without explicit declaration. Unnamed concepts referenced in multiple places. Overloaded terms where a single word carries two distinct domain meanings.

Language gaps are subtle and consequential. When "treatment" means both "the full clinical encounter" and "a single medical intervention," every conversation about treatments becomes ambiguous. The code will resolve the ambiguity — but it will resolve it silently, and different developers will resolve it differently.

Decision Gaps (DG) are architectural choices that haven't been made or haven't been documented. A bounded context boundary that could reasonably be drawn in two places. A relationship type that's assumed but not declared. A scope decision that's implicit rather than explicit.

Decision gaps are the gaps that define your architecture. The structural gaps and heuristic violations are usually mechanical to fix. The decision gaps require judgment, tradeoff reasoning, and the willingness to commit to a position and document why.

What a Gap Looks Like

Here's a structural gap from a real worked example — a veterinary clinic domain specification:

SG-01: Appointment aggregate has zero invariants

Severity: Error Rule: Aggregates must protect at least one invariant — an aggregate without invariants has no consistency boundary to enforce. Specification element: Appointment aggregate in Scheduling context Analysis: Appointment defines four commands and four events but no invariants. What prevents double-booking the same time slot? What prevents checking in a cancelled appointment? What prevents rescheduling to a time in the past? Without invariants, the Appointment aggregate is a data container, not a consistency boundary. Recommendation: Define invariants. At minimum: (1) No two appointments for the same veterinarian may overlap in time. (2) Appointment status must follow a valid lifecycle. (3) Rescheduled time must be in the future.

Notice the structure. The gap states what was measured (zero invariants), why it matters (no consistency boundary), what the consequences are (double-booking, invalid transitions), and what to do about it (define specific invariants). It's not a vague warning. It's an actionable diagnostic that tells you exactly where to look and what question to answer.

Here's a heuristic gap from the same domain:

HG-04: Zero sagas in a domain with multi-step processes

Severity: Warning Rule: Domains with cross-aggregate, multi-step processes typically require at least one saga. Metric: 0 sagas, 3 policies Analysis: The full visit lifecycle spans multiple aggregates across multiple contexts: Appointment → Visit → Treatment → Invoice. This is a multi-step process with potential failure points. What if treatment is started but the visit is never closed? What if the visit is closed but invoice generation fails? Policies handle the happy path. There's no compensation or failure handling. Recommendation: Evaluate the visit lifecycle as a saga candidate with compensation for each step.

And here's a decision gap:

DG-02: How does pricing work?

Severity: Error Analysis: PricingService "calculates line item prices based on treatment codes and clinic pricing rules." But there's no pricing model, no price list aggregate, no pricing configuration. Where do prices come from? Are they per-treatment-code? Per-veterinarian? Time-based? The service exists but its data model is undefined. Recommendation: Define a PriceList aggregate with pricing rules. Determine whether pricing is static or dynamic.

That decision gap is an error, not a warning, because it describes a domain concept that other parts of the specification depend on but that doesn't exist. Invoice generation references pricing. Pricing references nothing. There's a hole in the model where a concept should be.

The Three-Pass Trajectory

The gap report becomes powerful across passes. Here's what convergence actually looks like, from the veterinary clinic worked example:

Pass 1: 18 gaps identified. 5 errors, 13 warnings. The domain specification has all six aggregates named and placed. It has events flowing between contexts. It looks like a domain model. But three of six aggregates have zero invariants. The Treatment aggregate is a sequential pipeline pretending to be an aggregate. There's no saga handling a multi-step visit lifecycle. Billing has no pricing model. The veterinarian schedule doesn't exist as a domain concept.

Every gap gets resolved. The resolution log documents what was decided and why. 16 accepted as recommended, 2 accepted with modification, 0 rejected. The specification grows: invariants go from 5 to 12, a saga is introduced, two new aggregates are added, a language overload is fixed.

Pass 2: 5 gaps. Zero errors, 5 warnings. The structural problems are gone. What remains are refinement concerns — the saga needs a timeout, the walk-in path has an event ordering dependency, a pricing snapshot rule needs to be explicit. These are the decisions that define the architecture's resilience, not its structure.

All five resolved. The invariant count climbs from 12 to 18. Every aggregate now has at least one invariant. Every cross-context relationship is declared with a type. Every scope decision is documented.

Pass 3: Zero gaps. Zero errors. Zero warnings. Converged.

The trajectory — 18 → 5 → 0 — is the signal. It tells you the methodology is working. Each pass reduces the gap count because the previous pass's resolutions addressed the root causes, not just the symptoms. When you fix the aggregate that has no invariants, you also fix the downstream gaps that depended on that aggregate having a consistency boundary. Foundational decisions resolve first; dependent decisions cascade.

If Pass 2 had produced more gaps than Pass 1, that would be the most important signal: the specification is diverging, not converging. Something is structurally wrong — probably a foundational boundary decision that's incorrect, causing every resolution to introduce new inconsistencies. Non-convergence means stop, revisit the boundaries, and restart the pass.

The Resolution Log

The gap report identifies questions. The resolution log records answers. Every resolution documents three things:

The decision: What was chosen and what was rejected. An aggregate without invariants can be fixed by adding invariants (if it's a real consistency boundary) or dissolved (if it isn't). The resolution records which path was taken.

The rationale: Why this decision was made. This is the most valuable artifact SDD produces. Six months from now, when someone asks "why is this a saga instead of a policy chain?" the resolution log has the answer — with the gap that prompted the question, the alternatives considered, and the reasoning that led to the current design.

The structural impact: What changed in the specification. "+1 saga, +1 event, +1 invariant." This makes the change traceable and auditable. Every element in the final specification traces back to either the initial extraction or a specific gap resolution.

The resolution log is the architecture decision record that DDD always needed but never formalized at the domain modeling level. ADRs capture decisions about technology choices and system-level architecture. Resolution logs capture decisions about domain model structure — why this aggregate exists, why this boundary is drawn here, why this invariant matters.

Running Your Own Pass

You don't need tooling to try this. You need a domain specification and the gap report template.

Step 1: Pick a bounded context in your system. Write the domain specification — name every aggregate, every command, every event, every invariant, every policy, every saga. Make every relationship explicit. If you can't name it, it's a gap.

Step 2: Run the gap report against it. For each aggregate, ask: does it have invariants? For each command, ask: does it produce an event? For each bounded context, ask: are its relationships declared? Check the heuristic thresholds — command density, term overlap, saga step count. Look for language overloads and undocumented decisions.

Step 3: Write the resolution log. For every gap, decide: change the model or document why the current design is intentional. Record the rationale.

Step 4: Update the specification with the resolutions and run the gap report again. The gap count should drop. If it does, you're converging. If it doesn't, revisit your boundary decisions.

The SDD repository has everything you need — templates for all four artifacts and a complete worked example showing three-pass convergence. The veterinary clinic example walks through 18 gaps across three passes with full resolution rationale for every decision.

Why This Matters

The gap report solves a problem that every DDD practitioner has felt but few have named: the anxiety of not knowing whether the model is done.

You finish a domain modeling session. The event storming board is covered in stickies. The bounded contexts feel right. The aggregates have names. But there's a nagging uncertainty — did we miss something? Are the boundaries correct? Is that aggregate doing too much? Is that policy actually a saga?

Without a gap report, the only way to answer those questions is experience. The architects who've seen dozens of domain models can spot the patterns. The architects who haven't can't — and they won't know what they missed until implementation reveals it.

The gap report makes the experienced architect's intuition explicit, measurable, and transferable. It asks the questions that a senior DDD practitioner would ask. It flags the patterns that Evans, Vernon, and Brandolini documented. It forces the decisions that matter into the open where they can be examined.

Each gap is the question an experienced practitioner would ask. SDD asks it for you.

What Comes Next

Post 5 gives you the methodology to try. The repository gives you the tools.

But the gap report revealed something I didn't anticipate when I first built this process. When AI enters the domain modeling pipeline — when the specifications aren't authored by humans but generated by language models — a new category of failure emerges. Structurally valid models that are semantically wrong. Patterns that pass every gap report check but misrepresent the domain's actual behavior.

Post 6 introduces the first pattern that SDD surfaced about AI-mediated domain modeling: the Candidate Lifecycle.

This is Post 5 of a series on DDD, AI, and the methodology that emerged from practicing both rigorously. Post 4 introduced Signal-Driven Development. The series continues with AI-mediated domain modeling patterns starting in Post 6.

Introducing Signal-Driven Development

Sat, 21 Mar 2026 19:41:04 GMT

Not "done" in the project management sense — not "the sprint ended" or "the stakeholders signed off." Done in the engineering sense. Structurally complete. Semantically consistent. Ready for implementation with confidence that the architecture will hold.

Evans never answered this question. Neither did Vernon, Brandolini, or anyone else in the DDD community. And it's not because the question is unimportant — it's because the traditional answer was always implicit. You knew the model was done when the team stopped finding new insights during knowledge crunching. When the conversations with domain experts stopped producing surprises. When the event storming board stabilized.

That's not a definition of done. That's a feeling.

I spent the better part of a year doing rigorous domain modeling across multiple products — complex domains with regulatory concerns, event-sourced architectures, cross-context dependencies, and temporal behaviors that don't fit neatly into Evans's spatial model. I did this work as a solo practitioner with an AI collaborator, using the approach I described in the first three posts of this series.

What emerged wasn't just a set of domain models. It was a methodology. One with a measurable definition of done, a repeatable convergence process, and a feedback loop that makes domain modeling adversarial in the best sense of the word.

I'm calling it Signal-Driven Development.

The Core Problem: DDD Has No Feedback Loop

Domain-Driven Design gives you an extraordinary vocabulary for modeling complex systems. Bounded contexts. Aggregates. Domain events. Policies. Sagas. The building blocks are precise, expressive, and battle-tested across two decades of practice.

What DDD doesn't give you is a way to know when you've used them correctly.

Consider the typical DDD workflow. You do knowledge crunching — workshops, event storming sessions, whiteboard conversations with domain experts. You iterate on the model. You refine bounded context boundaries. You identify aggregates and their invariants. At some point, someone says "I think we're good" and the team moves to implementation.

But "I think we're good" is a subjective assessment. There's no structural verification. No way to measure whether the model is complete, whether the boundaries are consistent, whether the heuristics that Evans and Vernon established are actually being honored. The model might have an aggregate with twelve commands and no invariants — a consistency boundary that enforces nothing. It might have two bounded contexts sharing fifteen terms with identical definitions — contexts that aren't actually bounded. It might have a policy that emits six commands in response to a single event — a stateless reaction doing the work of a saga.

These aren't obscure edge cases. They're the gaps that every experienced DDD practitioner has learned to spot through years of pattern recognition and hard-won intuition. The gaps that junior architects miss entirely. The gaps that AI-generated models introduce systematically, because an LLM has no intuition — only statistical pattern completion.

DDD needs a feedback loop. Not a checklist. A diagnostic system that examines a domain specification structurally, measures it against the heuristics that the DDD community has established over twenty years, and produces a report that tells you exactly what's incomplete, what's inconsistent, and what violates the principles you claim to follow.

That feedback loop is what I'm calling a gap report. And the methodology built around it is Signal-Driven Development.

Three-Pass Convergence

SDD's core mechanic is structured convergence through iterative gap resolution. The process works like this:

Pass 1 produces a domain specification — the full structural model of your domain expressed in DDD building blocks. Bounded contexts, aggregates, domain events, commands, policies, sagas, projections, invariants, value objects, domain services. Everything named, everything placed, every relationship explicit. The gap report for Pass 1 identifies what the specification cannot answer: missing invariants, boundary violations, heuristic threshold breaches, methodology process gaps. In a complex domain, Pass 1 typically surfaces 20 to 35 gaps.

Pass 2 resolves those gaps. This is where the real architecture happens. You're not generating a model — you're interrogating one. Every gap is a question the specification couldn't answer. Some gaps resolve by adding missing elements (an aggregate without invariants needs invariants, or it needs to be dissolved). Some resolve by restructuring (two contexts with heavy term overlap need a boundary reassessment). Some resolve by making an explicit architectural decision and documenting why. The gap count drops — typically to 5 to 10. If it doesn't drop, the specification is diverging rather than converging, and that divergence is itself a diagnostic signal.

Pass 3 drives to zero. The remaining gaps are usually the hardest — the architectural decisions that require genuine tradeoff reasoning. A saga with seven steps that might need decomposition. A bounded context whose name doesn't match its actual responsibility. An aggregate whose event fan-out suggests it's doing too much. These are the decisions that experienced architects agonize over in whiteboard sessions. SDD forces them into the open by making them measurable.

The definition of done is zero unresolved gaps. Not "zero gaps identified" — gaps will always be identified. Zero unresolved gaps. Every gap has been examined, and for each one, the architect has either changed the model to address it or documented why the current design is intentional. The resolution is the artifact, not the absence of the finding.

Some domains require four or five passes. The three-pass label describes the typical trajectory, not a hard constraint. The invariant is convergence: each pass must reduce the gap count. If it doesn't, something is structurally wrong with the specification, and that non-convergence is the most important signal the process can produce.

Gap Reports as Diagnostic Signals

The gap report is the heart of SDD. It's not a test suite. It's not a linter output. It's a structured diagnostic that evaluates a domain specification against three categories of concern.

Structural completeness asks whether the specification has the elements it needs. Does every aggregate have at least one invariant? Does every bounded context have a clear linguistic boundary? Are there commands without corresponding domain events? Are there domain events that no policy or projection reacts to? These aren't style preferences — they're the structural expectations that Evans and Vernon established. An aggregate without invariants isn't a design choice; it's a consistency boundary that enforces nothing.

Heuristic thresholds measure whether the specification honors the quantitative guidelines the DDD community has developed through practice. Vernon's small aggregate heuristic suggests no more than six commands per aggregate. Context term overlap beyond three shared definitions suggests insufficient separation. Saga step counts beyond five suggest decomposition is needed. These thresholds aren't arbitrary — they're grounded in two decades of published work by Evans, Vernon, Brandolini, and others. They're configurable, because every domain has legitimate reasons to deviate. But deviations should be conscious decisions, not invisible accidents.

Methodology process gaps verify the discipline of the modeling process itself. Does every architectural decision have a documented rationale with at least one rejected alternative? Have gap resolutions been traced to specific changes in the specification? Is the gap count decreasing across passes? These are the meta-rules — the rules about the process, not the model.

The critical insight is that gap reports are signals, not verdicts. A gap doesn't mean the model is wrong. It means the model has a question it hasn't answered. The architect reads the signal, investigates, and either changes the model or documents why the current design is correct. Both outcomes are valid. The gap report's job is to surface the question. The architect's job is to answer it.

This is what makes SDD adversarial in a productive way. The gap report is the colleague who keeps asking "but why?" — not to obstruct, but to force the kind of rigorous reasoning that produces architectures you can defend under scrutiny.

The Architecture Palette

The third artifact in SDD — alongside the domain specification and the gap report — is the architecture palette. It's a visual projection of the domain specification expressed in DDD building blocks, organized by bounded context, showing the relationships between aggregates, events, commands, policies, and sagas.

The palette serves two purposes. First, it's a communication artifact. A domain specification can be hundreds of elements across dozens of pages. The palette compresses that into a visual map that an architect can hold in working memory. Second, it's a verification surface. Structural patterns that are invisible in a textual specification become obvious in a visual layout — an aggregate that's connected to everything, a bounded context with no outbound events, a saga that spans three contexts when it should span two.

The palette is the thing you put on the wall. The specification is the thing you trust. The gap report is the thing that tells you whether the specification deserves that trust.

What This Looks Like in Practice

I've run this process across eight product domains over the past year. Not toy examples — production systems with regulatory requirements, event-sourced architectures, and cross-product dependencies. Here's what the convergence trajectory actually looks like.

A typical Pass 1 gap report surfaces 20 to 30 findings. Five to eight are structural errors — missing invariants, aggregates without consistency boundaries, commands that don't produce events. Ten to fifteen are heuristic threshold violations — aggregates with too many commands, contexts with overlapping vocabulary, policies doing the work of sagas. The rest are methodology gaps — architectural decisions made without documented alternatives, gap resolutions without traceability.

Pass 2 resolves all of them. The structural errors are usually straightforward — add the missing invariant, dissolve the aggregate that has no reason to exist, split the policy into a saga. The heuristic violations require judgment — sometimes the threshold is right and the model needs to change, sometimes the domain genuinely requires a larger aggregate and the override needs to be documented. The methodology gaps are discipline — go back and document the reasoning.

Pass 3 finds the residuals. In a complex domain, there are usually two to five gaps that survived Pass 2 — often the ones that require genuine architectural tradeoffs. A bounded context boundary that could reasonably be drawn in two places. A saga decomposition that improves one metric at the cost of another. These are the decisions that define the architecture, and SDD's contribution is forcing them into explicit, documented, measurable resolution rather than leaving them as implicit assumptions buried in the code.

By the end of Pass 3, the gap count is zero. Every structural element has been verified. Every heuristic threshold has been honored or consciously overridden. Every architectural decision has been documented with alternatives considered and rationale recorded.

That's a definition of done.

The Part We Didn't Expect

I want to be transparent about the intellectual path that led here.

SDD emerged from practice. I didn't start with a methodology and apply it. I started with a problem — how do you do rigorous domain modeling without a room full of people? — and iterated on the process until something repeatable crystallized. The three-pass convergence, the gap report categories, the architecture palette, the definition of done — all of it came from doing the work and noticing what worked.

I didn't research what the DDD community's leading voices were currently publishing until months after the methodology had stabilized. When I finally did — when I read Evans's Explore DDD 2024 keynote, when I looked at what Domain Language is now focused on, when I read Khononov's work on coupling as a measurable heuristic — the convergence was startling.

Evans is now focused on integrating AI into domain-rich systems while preserving design integrity. His keynote framing — that a trained LLM on a ubiquitous language is effectively a bounded context — is the same conclusion I reached independently while building the constraints that keep AI output within a closed DDD vocabulary. Same destination, completely different paths. He's since published a follow-up on context mapping with AI-based components — drawing an Anti-Corruption Layer between deterministic application code and probabilistic LLM output. We built the same pattern independently.

Khononov's Balancing Coupling in Software Design (Addison-Wesley, 2024) formalizes coupling as a measurable design heuristic with an optimizable function — the same pattern as SDD's threshold model. Take the qualitative principles Evans established, make them quantitative, set configurable thresholds, measure against them. He arrived at it through academic rigor. I arrived at it through building a system that needed to verify domain models automatically.

DDD Europe 2026 has workshops on accelerating strategic design with large language models — Thomas Coopman's two-day session in Antwerp this June. The community is mainstreaming the intersection of AI and DDD as a topic. We've been living in that intersection for months.

I'm not claiming priority. I'm observing convergence. When independent practitioners arrive at the same conclusions from different starting points, it's not a coincidence — it's the problem asserting its own shape. The DDD community is converging on the need for measurable heuristics, AI-mediated modeling, and structural verification because those are the problems that surface when you take DDD seriously at scale. Whether you start from Evans's theory or from a solo practitioner's frustration, the same walls appear.

The domain specification that emerged from three-pass convergence was structurally complete enough to verify context provenance — without a single line of implementation code. The design was the proof.

That's not a theoretical claim. That's a measured result from applying this methodology to a real product domain. The specification produced by SDD's convergence process contained enough structural information that compliance verification could be performed against the domain model directly — before any runtime existed to test against. The architecture didn't need to be built to be verified. It needed to be modeled rigorously enough that verification was a projection of the model itself.

What SDD Is Not

SDD is not a replacement for DDD. It's an extension. Evans gave us the building blocks — the vocabulary for decomposing complex domains into bounded contexts, aggregates, and domain events. Vernon gave us the implementation patterns — the tactical guidance for turning those building blocks into working code. Brandolini gave us the discovery vocabulary — Event Storming as a method for collaborative knowledge crunching. Narrative-Driven Development gave us the temporal dimension — the recognition that domains exist in time, not just in space.

SDD gives DDD a feedback loop and a definition of done.

The gap report doesn't replace knowledge crunching. It makes knowledge crunching measurable. The three-pass convergence doesn't replace architectural intuition. It forces intuition into the open where it can be examined, challenged, and documented. The architecture palette doesn't replace event storming boards. It persists them.

If you practice DDD, you can practice SDD tomorrow. The process is the same — model the domain, interrogate the model, refine the model. SDD adds structure to the interrogation and a measurable endpoint to the refinement.

What Comes Next

The templates are coming — gap report templates, architecture palette formats, domain specification structures. Everything you need to run a three-pass convergence on your own domain. I'll share them through a public repository designed for practitioners who want to try SDD on a real project, not a tutorial exercise.

Post 5 will go deep on the gap report itself — what the categories look like, how the three-pass trajectory works in detail, and how to read the signals that a gap report produces. That's where the methodology becomes concrete enough to apply.

But the gap report is just the beginning. SDD surfaced patterns I didn't anticipate — patterns about what happens when AI enters the domain modeling process, about what structural verification reveals when it catches problems that humans can't see, about what a rigorous feedback loop does to the quality of architectural decisions over time.

Those patterns are the subject of the rest of this series.

SDD doesn't replace DDD. It gives DDD a definition of done.

This is Post 4 of a series on DDD, AI, and the methodology that emerged from practicing both rigorously. Posts 1–3 established the solo-builder problem, the AI collaboration model, and the vocabulary gap. The series continues with a deep dive into the gap report in Post 5.

The Coherence Problem

Mon, 16 Mar 2026 06:42:13 GMT

Everyone's celebrating velocity. Nobody's talking about what happens when you succeed.

Everyone's talking about AI making solo developers faster.

Ship a SaaS in a weekend. Replace your junior devs. Build an MVP before lunch.

Cool. But nobody's talking about what happens when you succeed.

The Week That Changed My Framing

I spent the last week maintaining a multi-product software ecosystem — alone, with AI as my architecture partner. Not generating code. Not shipping features. Managing the coherence of a system that's grown complex enough to behave like a team-scale project.

One architectural decision triggered documentation updates across 21 pages. A single boundary change cascaded through 5 product requirement documents, 4 platform-level architecture decision records, and a dozen cross-references that all needed to stay internally consistent.

That's not a speed problem. That's a coherence problem. And it's the problem nobody warns you about when they celebrate the solo AI dev.

Speed vs. Coherence

Here's what I've learned building this way:

AI doesn't make you faster. It makes you capable of holding more complexity in working memory than one person should be able to.

That's a fundamentally different thing.

Speed means you do the same work in less time. Coherence means you do work that wasn't possible before — maintaining the kind of cross-system architectural consistency that used to require a team of people whose entire job was keeping the model straight.

When I work with AI on architecture, the value isn't autocomplete. It's that my AI partner can hold the full specification of a multi-product ecosystem in context while I make a decision — and then execute the downstream implications of that decision across every artifact it touches. In real time. Without drift.

A human team doing this would need an architect who understands the decision, a technical writer updating the docs, a project manager tracking the cascade, and a QA engineer verifying consistency.

I have one terminal and a conversation.

The Part Nobody Warns You About

But here's the part the "AI productivity" narrative misses entirely:

The system got complex enough that I had to build a new service just to manage the dependency graph between my own architectural artifacts.

Read that again.

I didn't build it because I wanted to. I built it because the cascade problem — one change rippling through dozens of documents — became its own engineering challenge. The AI partnership made me productive enough to create a system that now requires its own tooling to maintain.

That's not a failure. That's what real architecture looks like. It's just that most solo developers never get there because without AI, the complexity ceiling hits you long before the architecture demands it.

The Question Nobody's Asking

The discourse right now is fixated on velocity. How fast can you ship. How many lines of code per day. How quickly you can go from idea to deployment.

I'd argue the more interesting question is:

How much architectural integrity can one person sustain?

Because the companies that win long-term aren't the ones that shipped fastest. They're the ones whose architecture held up when it mattered — when the edge cases arrived, when the compliance audit landed, when the system had to evolve without a rewrite.

If AI is genuinely changing what a solo builder can accomplish, the interesting frontier isn't "build it faster." It's build it with the kind of structural rigor that used to require a team standing behind you.

The solo dev + AI revolution is real. I'm living it.

But if all you're using AI for is speed, you're solving the wrong problem. Speed was never the bottleneck. The bottleneck was always one person trying to hold an entire system in their head without losing the thread.

AI doesn't speed up that work. It makes it possible for the first time.

That's the unlock. Not velocity. Coherence.

The Single-Seat Architect

Mon, 16 Mar 2026 06:14:10 GMT

A lot of professionals aren't making it back into the market.

That's not a prediction. That's what's happening right now. And if you're in this industry, you already know someone it's happened to. You probably just haven't said it out loud yet.

So let me say it.

How We Got Here

A non-trivial percentage of CEOs discovered ChatGPT sometime in the last two years. They typed a prompt. They got something back that looked like a product spec, or a business plan, or a chunk of code. And something broke in their brain.

They didn't learn what AI can do. They learned what AI looks like it can do. And that's a dangerous distinction — because now they think building software is easy. They think the reason it was hard before was the developers, not the problem. They think the $200/hr architect was overhead, not the only person in the room who understood why the last three projects failed.

This isn't new. Developers have been treated like they were a dime-a-dozen for fifteen years. Every outsourcing wave, every bootcamp boom, every "we'll just hire three juniors instead of one senior" decision — it all came from the same place: the belief that software is a labor problem, not a thinking problem.

AI didn't create that delusion. It compounded it.

What Actually Changed

Now the thinking goes: if AI can generate code, why do I need a team? If ChatGPT can write a PRD, why do I need a product person? If I can get a working prototype in a weekend, why was that project estimated at six months?

And here's the thing — they're not entirely wrong that the landscape changed. They're just catastrophically wrong about what changed.

What changed isn't that software got easier to build. What changed is that the floor collapsed. The baseline tasks that used to require a human — writing boilerplate, translating specs into code, wiring up CRUD endpoints — those aren't jobs anymore. They're prompts.

The hard problems are exactly as hard as they were before AI. System design. Ambiguity resolution. Figuring out why the requirements contradict each other before you've built the wrong thing for six months. Understanding regulatory constraints. Knowing when the architecture will collapse under scale and why. Making trade-offs between consistency and availability when a product person is staring at you waiting for a yes.

AI can't do any of that. Not because the models aren't good enough yet. Because those problems require judgment, context, and the kind of earned intuition that only comes from having been wrong enough times to recognize the shape of the next mistake before you make it.

The Other Side

I know this because I lived the other side of it.

I spent three quarters unemployed last year. Twenty-plus years of building software, and I couldn't get back in. Companies everywhere were claiming they were hiring, but I honestly don't think 90% of them were. Many were preparing for headcount budgets that never materialized. Others were taking advantage of a flooded market, low-balling experienced engineers 50 to 70 percent below their market rate — and finding takers, because people were desperate.

The market was nasty. From what I'm hearing, it still is.

And while I was in that gap, I watched the AI narrative accelerate in real time. Every week, another LinkedIn post about shipping a product in a weekend. Another CEO tweeting about replacing their engineering team. Another think piece about how developers need to "adapt or die" — written by someone who's never had to adapt to anything harder than a new iPhone.

Who's Actually Coming Back

But here's what I noticed from the other side.

The professionals starting to make it back aren't the ones with the deepest specialization. They're the ones with the widest experience. The developer who also understood product. The backend engineer who also did infrastructure. The architect who'd sat in sales calls and heard what the customer actually needed versus what the ticket said.

They didn't just learn to code. They learned to think across boundaries. And now, paired with AI, those people are devastating.

A new role is settling under that collapsing floor. I'd call it the single-seat architect — someone who spent years accumulating lateral experience across product, engineering, data, infrastructure, and operations, and who now discovers that AI gives them the leverage to build entire products on their own.

Not prototypes. Not MVPs held together with API calls and prayer. Actual products with real architecture, real domain modeling, real compliance, real coherence across every layer of the stack.

That's not hype. I'm building this way right now — solo, with AI as my architecture partner. The rigor isn't lesser because there's no team. It's different. AI doesn't replace the people I've worked with over the years. It replaces the limitations of working alone.

The Uncomfortable Part

The market isn't going to correct for this kindly. There will not be a gentle transition period where displaced specialists reskill into architects over a few months of online courses. Architecture isn't a certification. Lateral thinking isn't a bootcamp. The judgment that makes someone valuable in the AI era was built over years of cross-disciplinary work — product decisions, infrastructure trade-offs, customer conversations, failed projects, recovered projects.

You can't speedrun that.

So when I hear people say "AI won't replace developers, it'll just change what developers do" — I think that's a comforting lie dressed up as optimism. AI is already replacing developers. What it won't replace is the person who knows which problem to solve, how the pieces fit together, and what's going to break at 3 AM when the architecture can't support what sales just promised.

If that's you — if you spent your career going wide instead of just deep — this is your moment. The market has never valued lateral thinkers more than it does right now, even if it doesn't know how to say that in a job posting yet.

And if that's not you yet — stop learning another framework. Start learning an adjacent discipline. Product. Data. Infrastructure. Compliance. Sales. Anything that forces you to think about software as a system rather than a stack.

The floor is gone. Nobody's going to rebuild it for you. Not your employer. Not a bootcamp. Not the next framework.

But if you've spent your career learning how things break — not just how they're built — you don't need a floor. You never did. The floor was for people who needed something to stand on. You're the person other people called when the floor gave out.

That hasn't changed. The market just forgot for a minute.

Remind them.

The Reactive Path Has No Vocabulary

Tue, 10 Mar 2026 09:45:42 GMT

I've been practicing Domain-Driven Design for over a decade. I've built event-sourced systems. I've implemented CQRS. I've drawn bounded context boundaries, defined aggregates, modeled domain events with intentional language. I'd have told you, with confidence, that I understood the methodology.

Then I ran a structured assessment on my own knowledge and found a gap I'd been building around for years.

Not a minor gap. Not an edge case or an advanced technique I hadn't gotten to yet. A fundamental gap in how I modeled half of every system I'd ever built.

I want to tell you what it was, because I think it reveals something about how DDD actually transfers knowledge — and why that transfer mechanism fails for more people than anyone admits.

Here's the setup. If you've worked with event-driven architecture, you know there are two sides to the system. There's the command path — where requests come in, business rules get enforced, and domain events get emitted. And there's the reactive path — where those events get consumed and the system responds.

My command path was clean. Domain-organized. Rigorous naming. Aggregates enforced invariants. Commands expressed intent in business language. Value Objects carried meaning. If you read the command side of my code, you could understand what the business did.

My reactive path was a different story.

Every function that consumed a domain event was an "event handler." That was the entire vocabulary. Hundreds of functions across multiple systems, all filed under one undifferentiated category. Some of them transformed data into read models. Some of them evaluated conditions and issued commands to other aggregates. Some of them coordinated multi-step workflows across time, tracking state across multiple events. All of them were "event handlers."

I wasn't modeling the reactive side of my systems. I was just coding it.

I wasn't modeling the reactive side of my systems. I was just coding it.

The gap became visible when I ran a structured assessment — a systematic walk through DDD's conceptual landscape, starting from philosophical foundations and working forward through tactical patterns, strategic design, and the post-Evans vocabulary that's emerged in the last twenty years.

I did this with an AI collaborator, specifically to pressure-test what I thought I knew against what I actually knew. Not to learn DDD from scratch — to find the holes that years of practice had papered over.

The hole appeared in the reactive path.

The DDD community — particularly through practitioners like Alberto Brandolini's Event Storming work and the broader Narrative-Driven Development (NDD) movement — has developed precise vocabulary for the reactive side of a system. Three concepts, each with distinct responsibilities:

A Projection is pure data transformation. An event arrives, data moves into a read model. No business logic. No decisions. Just reshaping data for consumption.

A Policy is a decision point. "When X happens, evaluate a condition, and if it holds, issue command Y." One event in, one command out. Stateless. The bridge between "something happened" and "decide what to do about it."

A Saga is coordination across time. "When X happens, do Y, then wait for Z, then if Z succeeds do W, but if Z fails compensate by doing V." Stateful. Tracks progress across multiple events and commands. No single aggregate owns the flow — the saga manages it as a long-running process.

These are not interchangeable. A projection has no business logic. A policy makes a single decision. A saga tracks state across steps. They have different responsibilities, different stateful characteristics, different failure modes, and critically, different testing strategies. Treating them as the same thing — "event handlers" — collapses three distinct architectural concerns into one bucket.

That's exactly what I'd been doing. Across every system I'd built.

And here's the part that stung: I'd read about all three. I'd encountered the terms. I could have given you a textbook definition of each one. But textbook definitions and operational understanding are completely different things. The concepts existed in my reading vocabulary but not in my modeling vocabulary. I knew the words. I didn't use them to think.

This is where Evans's deeper insight about language hits home — the one most practitioners skim past on their way to learning aggregate patterns. Evans embedded a claim in DDD that comes directly from linguistics: the Sapir-Whorf hypothesis. The idea that the language available to you shapes — and constrains — what you can think.

If you don't have a word for something, you will struggle to model it.

I didn't have operational words for the reactive path. So I didn't model it. I coded it. The functions worked. The events got processed. But the structural distinctions that would have made the architecture legible, testable, and evolvable were absent — not because the code was wrong, but because the vocabulary I was thinking in didn't make the distinctions visible.

If you don't have a word for something, you will struggle to model it. I didn't have operational words for the reactive path. So I didn't model it.

The moment the vocabulary landed — the moment "event handler" split into "projection," "policy," and "saga" as distinct concepts in my working mental model — I could suddenly see the structure that had been invisible. This function is a projection: it has no business logic, it just reshapes data. That function is a policy: it evaluates a condition and issues a command. That other function is actually a saga: it's tracking state across multiple steps, and the fact that it doesn't have explicit compensation logic is a bug, not a feature.

The assessment didn't teach me something I'd never heard of. It surfaced something I'd heard of but never internalized — because the environment in which I practiced DDD never forced the internalization.

And that's the real finding. Not the gap itself, but why the gap existed.

DDD transmits its deepest knowledge through team osmosis. You sit in a room where a senior practitioner points at a reactive flow and says "that's a policy, not a saga — here's why the distinction matters." You absorb the vocabulary not through reading but through repeated exposure in collaborative contexts where the terms carry operational weight. The naming happens in the room, during modeling sessions, through productive disagreement about what things are.

If you've never been in that room — if you're a solo practitioner, or you work on a team where nobody has that vocabulary, or you crossed into DDD from a team that practiced it implicitly without naming the patterns — those concepts stay in the reading layer. You know the words. You can define them on a whiteboard. You just don't reach for them when you're actually modeling, because they never crossed from knowledge into instinct.

DDD transmits its deepest knowledge through team osmosis. If you've never been in the room where the naming happens, the concepts stay in the reading layer.

This isn't a gap that reading fixes. I'd read about policies and sagas. The books were on my shelf. The gap persisted because reading is not the same as being challenged to apply the vocabulary under pressure, in the context of a real system, where someone asks "is that a policy or a saga?" and you have to answer with consequences.

The structured assessment recreated that challenge. It forced me to walk through my own architecture and name things — not in the abstract, but against real systems I'd built. And when the naming forced a distinction I'd never made, the gap was visible.

One gap. Found in days. After being invisible for my entire career.

That tells me something about DDD's accessibility problem that goes beyond the solo-builder framing I've been writing about. The problem isn't just that solo builders lack teams. It's that the methodology's most important knowledge transfers through a channel — collaborative practice with experienced practitioners — that has no fallback. If the channel isn't available, the knowledge doesn't transfer. Not because the practitioner is lazy or the books are bad. Because some knowledge only crystallizes under pressure, and pressure requires a counterpart.

The assessment I ran proved that the counterpart doesn't have to be a human team in a physical room. But it does have to exist. And the fact that this gap persisted — a gap the community had named, published about, and built tooling around — suggests that a lot of practitioners are carrying similar invisible gaps right now.

Not because they haven't studied. Because the transfer mechanism DDD depends on doesn't reach them.

What I'm sitting with now is a follow-up question: if one structured assessment can surface a long-standing gap in a few days, what would a systematic methodology for this kind of diagnostic look like? Not a coaching plan. Not a reading list. A repeatable discipline that any architect can apply to their own understanding and their own systems.

I have some ideas. More on that next.

This is the third post in a series on rigorous domain modeling without a team. Previously: DDD Has a Solo-Builder Problem and Knowledge Crunching Doesn't Need a Room.

Knowledge Crunching Doesn't Need a Room

Tue, 10 Mar 2026 08:35:16 GMT

Most people think the hard part of domain modeling is learning the patterns. Aggregates, entities, value objects, domain events, repositories — the tactical toolbox. There are books, courses, conference talks, and GitHub repos dedicated to teaching you the building blocks.

The building blocks aren't the hard part.

The hard part is the moment someone says "we approve claims" and you have to decide whether approval is a command on the Claims aggregate, a policy triggered by an upstream event, a saga that orchestrates across multiple contexts, or all three depending on the claim type and the regulatory jurisdiction.

The hard part is drawing a bounded context boundary on Tuesday that feels clean and coherent, then realizing on Thursday that an invariant you didn't consider means two things you separated actually need transactional consistency — which means they belong in the same aggregate, which means your context boundary is in the wrong place, which means the event contract you designed between those contexts no longer makes sense.

The hard part is holding six bounded contexts in your head simultaneously, knowing that a decision in Context Three depends on something you resolved in Context One, and that both cascade into how Context Five consumes events. Every boundary decision has downstream consequences. Every downstream consequence can invalidate upstream decisions. The model is a web of interdependencies, and the only way to validate it is to trace through the whole thing at once.

This is what Eric Evans meant by knowledge crunching. Not learning patterns — resolving ambiguity. Two or more people sitting with a domain until the model gets sharp enough to survive contact with reality. The patterns are the vocabulary. Knowledge crunching is the conversation.

And that conversation is relentless. It's not a meeting you schedule. It's the continuous, grinding process of someone saying "what about this case?" and the model either absorbing the question or breaking under it. When it breaks, you reform it. When it absorbs, you move to the next question. The model converges through pressure.

Here's what that pressure actually looks like in practice.

I was working through a domain specification for a system with six bounded contexts. Somewhere around the third context, the model exceeded what I could hold in working memory simultaneously. Not because the individual pieces were complex — each context was tractable in isolation. But the integration points between them weren't. The aggregate boundaries in Interpretation depended on decisions made in Ingestion. Those decisions had downstream consequences for how Structural Analysis consumed events. And Structural Analysis fed back into the gap report that could invalidate the original Interpretation boundaries.

In a team, this is where you call a meeting. Get the owners of each context in a room. Walk the whiteboard. Each person holds their slice deeply and the adjacent slices loosely. The integration points live in the conversation between people. That's the whole point of the room — to synchronize what's in six different heads into one coherent model.

The room works because it distributes the cognitive load. No one person needs to hold the full model. The team holds it collectively, and the conversation is the synchronization mechanism. When someone challenges a boundary, the person who owns the adjacent context can immediately respond with "that breaks my event contract" or "that actually solves a problem I've been sitting on." The model gets refined through distributed challenge.

Without the room, the cognitive load doesn't distribute. It stacks. Every context, every boundary, every event flow, every cascade sits in one head. And working memory has hard limits. So you do what any reasonable person does — you simplify. You make the boundary decision that feels right for the context you're focused on, without fully tracing the cascade to all six contexts. You defer the integration questions. You move forward.

And then you discover the problems during implementation, when the cost of correction is highest. Exactly the failure mode DDD was designed to prevent.

This is the structural problem underneath the solo-builder problem I wrote about last time. It's not just that solo builders lack the team. It's that the specific thing the team provides — distributed cognitive load under continuous challenge — is the mechanism that makes domain models converge. Without it, models don't get wrong. They get shallow. They survive the easy questions and collapse on the hard ones.

Without it, models don't get wrong. They get shallow. They survive the easy questions and collapse on the hard ones.

So the actual question isn't "how do you do DDD alone." It's "how do you recreate the conditions under which ambiguity gets resolved." You need sustained challenge across the full model. You need a counterpart that holds the complete state while you interrogate specific corners of it. You need someone who asks "what happens when step three fails after steps one and two have already committed?" at the exact moment you're tempted to model a saga as a simple policy because the simpler pattern is faster to think through.

This is what I discovered — accidentally, honestly — when I started using AI as a domain modeling collaborator. Not a code generator. Not an architecture advisor. A collaborator in the Evans sense: a counterpart in the knowledge crunching process.

What surprised me wasn't that it could discuss DDD patterns. Any LLM can recite the difference between a saga and a policy. What surprised me was what happened when the model got large.

When I challenged a boundary decision in the third context, the AI didn't respond to that question in isolation. It held the full state of all six contexts — every aggregate, every event flow, every policy trigger — and surfaced the cascade. "If you move this aggregate, it breaks this event contract in Context Two, which means this saga in Context Five needs to change from choreography to orchestration." The full trace. Immediately. Without being asked to check.

No human collaborator does that. Not because they aren't capable, but because working memory has limits. In a team of six, each person holds their context deeply and the adjacent contexts loosely. The integration points live in the gaps between people's heads. That's why you need the room — to synchronize those gaps. The AI doesn't have gaps. It holds the full model at the same fidelity across all contexts, all the time.

This changed the nature of the collaboration in a way I didn't anticipate.

In a team, challenging a decision carries social cost. You're questioning someone's judgment. Even in healthy teams, there's friction. So you pick your battles. You challenge the decisions that feel most wrong and let the merely suboptimal ones pass. That's rational. You can't challenge everything.

With an AI collaborator, the cost of challenge drops to zero. Every decision gets pressure-tested. Every boundary gets interrogated. Not once — dozens of times, across dozens of decisions, without anyone getting tired or defensive. You end up in genuine friction: you challenge a boundary, the AI pushes back with a structural argument, you counter with a domain argument, the model sharpens. That cycle repeats until the model absorbs the pressure or you explicitly decide to defer.

I'll give you one specific moment that stuck with me.

The specification had a multi-step refinement flow. I'd modeled it as a policy — "when this event arrives, do this thing." Quick. Clean. Easy to reason about. The AI challenged the classification and walked through a failure scenario: what happens when step three fails after steps one and two have already committed? A policy doesn't track state across steps. A policy doesn't compensate for partial completion. That's a saga.

I knew the difference between policies and sagas. I'd implemented both. But in the flow of modeling, without someone in the room to ask "what happens when it fails?", I'd reached for the simpler pattern. Not out of ignorance — out of the natural tendency to simplify when there's no one applying counter-pressure in real time.

That single challenge — one question about a failure path — changed the specification's reactive architecture. And it was the kind of question that should surface during modeling but often doesn't — even in teams.

This is the part that's uncomfortable to admit. The room doesn't always work. Teams have the potential to provide sustained structural challenge, but in practice, that potential goes unrealized more often than anyone wants to acknowledge. Meetings run long. The whiteboard session covers the happy path and someone says "we can figure out failure handling during implementation." The saga-versus-policy distinction doesn't get raised because the person who would have caught it is focused on their own context, or didn't attend, or didn't push hard enough because the meeting was already over time.

And then someone discovers the problem six weeks into implementation, when step three fails and steps one and two have already committed and there's no compensation logic because nobody modeled the failure path. The rework isn't just code — it's architecture. The cost multiplier is enormous. That's the painful reality of DDD in practice: the methodology is designed to surface these questions early, but the delivery mechanism — team collaboration under time pressure — frequently lets them through.

The methodology is designed to surface these questions early, but the delivery mechanism — team collaboration under time pressure — frequently lets them through.

Over the course of that specification, I resolved over thirty structural gaps through this kind of back-and-forth. Not gaps the AI found on its own — gaps that surfaced because the collaboration forced both sides to be precise. The AI would propose a boundary. I'd reject it because it violated a domain invariant I hadn't articulated yet. The act of articulating it refined the model. The model converged through pressure. Exactly the way Evans described. Just without the room.

I want to be honest about what this isn't. It's not a replacement for a team. A team brings diverse domain expertise — people who've lived inside a business for years and carry implicit knowledge no specification captures. A team brings political context about organizational boundaries that should inform where bounded contexts land. A team brings the kind of cross-functional challenge where a product owner says "that's not how the business works" and the model changes in a direction no architect would have found alone.

But for the structural discipline — the systematic challenging of every boundary, every classification, every event flow against the full model state — an AI collaborator with perfect recall and zero social cost of disagreement is more effective than I expected. Not because it knows the domain. Because it doesn't let you skip the hard questions.

The conversation is different than what anyone expected. It's not "AI generates domain models." It's "AI recreates the forcing function that makes domain models converge."

It's not "AI generates domain models." It's "AI recreates the forcing function that makes domain models converge."

The methodology still works. The collaboration just looks different.

This is the second post in a series on rigorous domain modeling without a team. Next: what a decade of DDD practice missed — and how a structured assessment surfaced it.

DDD has a solo-builder problem, and nobody talks about it.

Mon, 09 Mar 2026 05:57:02 GMT

Every serious architect I know agrees: if you're building software for a complex domain, Domain-Driven Design is the gold standard. Evans was right. Vernon was right. The methodology works.

But here's the thing nobody says out loud — it was designed for teams.

Knowledge crunching, the beating heart of DDD, is a collaborative act. Evans describes it as continuous conversation between developers and domain experts. Two or more humans in a room, wrestling with ambiguity until a shared model emerges. The developer learns the domain. The expert learns to see their own knowledge structured differently. The model is the artifact of that collision.

Event storming? You need a wall, sticky notes, and a room full of people who disagree productively. Context mapping? That's a negotiation between teams about how their models relate. Strategic design? It assumes you have multiple bounded contexts owned by multiple groups, and the hard part is drawing the boundaries between them.

Every foundational practice in DDD assumes you're not alone.

So what happens when you are?

There are thousands of architects building serious systems by themselves. Startup founders. Solo technical leads. Indie builders working on domains complex enough to warrant DDD — healthcare, finance, logistics, compliance — but without a cross-functional team to practice it with.

They know DDD is the right approach. They've read the blue book. Probably the red book too. They can recite the tactical patterns in their sleep: aggregates, entities, value objects, domain events, repositories.

But the strategic work — the part that actually matters — requires a kind of collaboration they don't have access to.

What most of them do instead is predictable and understandable. They adopt the tactical patterns without the strategic discipline. They define aggregates without doing bounded context analysis. They emit domain events without modeling policies or sagas. They build what looks like DDD from the outside but is really CRUD with fancier names.

This isn't a criticism. It's a structural problem with the methodology's delivery mechanism.

DDD transfers knowledge through team osmosis. The junior developer absorbs strategic design instincts by sitting in rooms where those conversations happen. The mid-level architect internalizes bounded context boundaries by watching senior practitioners negotiate them across teams. The vocabulary gets transmitted through practice, not just through books.

If you don't have the room, the team, or the senior practitioner next to you, whole layers of the methodology become invisible. Not wrong — invisible. You don't know what you're missing because the gaps are in the implicit knowledge that DDD assumes you'll acquire through collaboration.

DDD transfers knowledge through team osmosis. If you don't have the room, the team, or the senior practitioner next to you, whole layers of the methodology become invisible.

I'll give you one example from my own experience. I've been practicing DDD for over a decade. I'd have called myself competent. Comfortable with aggregates, event sourcing, CQRS, the whole stack.

Then I ran a structured assessment on my own understanding and found a gap I didn't know existed: I had no vocabulary for the reactive path.

My command-side architecture was clean. Domain-organized. Rigorous language. But the event-handling side — the part where "something happened" turns into "decide what to do about it" — was an undifferentiated mass of event handlers. No structural distinction between a policy, a saga, and a projection. All lumped under "event processing."

I wasn't modeling half of my system. I was just coding it.

That gap didn't come from laziness or lack of reading. It came from never having sat in a room where someone pointed at a reactive flow and said "that's a policy, that's a saga, and here's why the distinction matters." The concepts existed in the literature. The community had named these patterns clearly. But without the team context where that vocabulary gets transmitted through practice, I'd been building around the gap for years without seeing it.

That's one architect. One gap. Found after a decade.

Now multiply that across every solo practitioner who's doing their best with DDD but missing the collaborative forcing functions that the methodology was designed to run on.

The patterns are accessible. The books are available. The conference talks are on YouTube. None of that replaces the thing DDD actually depends on: two or more people challenging each other's understanding of a domain until the model gets sharper.

This raises a question I've been sitting with.

Is DDD's accessibility barrier the methodology itself? Or is it the assumption that practicing it requires a team?

Because if it's the latter — if the hard part isn't the concepts but the delivery mechanism — then the question isn't how to simplify DDD. It's how to give solo practitioners access to the collaborative pressure that makes it work.

That's not a tooling question. It's not about generating code or automating boilerplate. It's about whether you can recreate the conditions under which domain models get refined: sustained challenge, systematic feedback, and a counterpart that holds the full model in working memory while you interrogate specific corners of it.

I don't think the answer is "just find a team." For a lot of builders, the team isn't an option. The domain is still complex. The system still needs to be built right.

DDD has a solo-builder problem. And until we acknowledge it, thousands of architects will keep building halfway — tactical patterns without strategic discipline, domain events without the conversations that give them meaning.

The methodology works. The question is who gets to use it.

This is the first post in a series exploring what rigorous domain modeling looks like when you don't have a team in the room. More soon.