Can a model produce a domain-driven design specification? (devs)

Community
, ,
1

Hey, the following was written by the bot under my supervision (don’t read it if you don’t like AI writing :slight_smile: )

Spent several hours today working with my agents on one idea: can a model take a plain text description of a business and produce a real DDD specification out of it? Entities, aggregates with invariants, bounded contexts, the actual thing.

Quick background on why this is interesting. There is a fresh paper from TU Munich, “Automating Domain-Driven Design: Experience with a Prompting Framework” (arXiv 2603.26244), where they split DDD into five prompt steps and tested it on a real enterprise platform with the company’s own architects judging the output. Glossary and event storming came out well, bounded contexts partially, and at the aggregates step it collapsed. Their experts said fixing the generated aggregates would cost more than designing them by hand, and step five they recommend skipping entirely. The cause they name: small errors accumulate from step to step until the model is building on garbage.

My take is that error accumulation is a provenance problem. The model invents a small plausible detail early, repeats it, and two steps later it reads like a requirement because it has a history. Real input and old hallucination look identical on the page. So instead of better prompts, I went for bookkeeping: the model is not allowed to trust the input text or itself. It turns the description into questions instead of assumptions, every value in every artifact carries who decided it (quoted from the owner, derived, or a logged default), anything irreversible it refuses to decide and builds as a disabled switch for the owner to turn on, and a separate model instance reviews the whole chain with a checklist in a fresh context.

Where it stands after today. Input was deliberately tiny, three sentences describing a bicycle repair shop. Out of them: about 150 explicit questions, a decision round under written policies, a full reconstruction of the business as text, a self review that found 19 inconsistencies across its own earlier artifacts (including a few I had missed when checking it myself), and finally the classification: entities and value objects each with their test traces, nine aggregates with invariant tables where every row cites the quote or decision forcing it, bounded contexts defined by the meaning they protect. The aggregates step went through, and the reason looks boring: bookkeeping, not intelligence.

Honest limits: one run, toy scale, and nothing is automated yet. Two concurrent models following the pipeline documents, with me as the transport layer between two chat windows, so copy-pasting is fun.

Still working on it, next is a verification pass and then the schema should fall out mechanically. I’ll keep posting here as it moves. If anyone wants the details or the method documents, let me know.

2

Entity vs value object: the one test that actually decides

Small teaser from the DDD pipeline work I posted about. Before any of it could run, I needed definitions a model can apply mechanically, and the textbook ones don’t survive contact. Mutability, having behavior, being persisted, “conceptual identity”: every one of these criteria breaks on the first counterexample. Money is a value object full of behavior. Plenty of entities are anemic bags of data. So we stripped it down until one distinction remained.

The definitions

An occurrence is a happening in the domain. Two occurrences can be identical in every recorded value and still be two. That’s the whole foundation.

An entity is a representation the domain must keep distinct from its value-identical twins.

A value object is a representation where any equal one is as good as any other. Interchangeable by definition.

Identity is not a property you discover on the thing. It’s a mechanism you add to prevent two equal representations from collapsing into one. It has three origins: assigned (you mint a number), adopted (taken from outside, like a barcode already on the item), or natural (a position, a timestamp, a place in a sequence that already keeps twins apart).

The test

Take two of them with exactly equal values. Merge them into one. Does any fact disappear?

A borrowed book gathers one late fee entry per late day, same amount every day. Two entries of 0.50 are two days late. Merge them and the member’s debt silently halves. A fact died, so the fee entry is an entity, and it needs identity even though no user will ever ask for “fee entry #4382”.

The due date on that same borrowing: merge two equal due dates and nothing happens, nothing was ever lost. Value object.

That’s the entire rule. If merging equal ones destroys a fact or corrupts a total, it’s an entity. If nothing breaks, it’s a value object, and giving it identity is just noise in your schema.

Two bonus observations that fell out of testing this with models. First, classification is per bounded context: the same concept can be a value object in one context and an entity in the next (a banknote is a value in a shop and an entity at the mint that tracks serial numbers). Second, the language already tells you: things people address on their own (“the borrowing”, “the ticket”) tend to be entities, things reachable only through their owner (“the due date of the borrowing”) tend to be values. Grammar knows before you do.

In the pipeline these definitions live in a method document, and the model runs the merge test on every candidate with a quote from the source as evidence, so every verdict carries its trace. More on that in the next posts. If you want the full document, let me know.

me: have fun! great day to everyone, getting off that crazy shift

P. S. Confirmed, what came out of several lines about a bicycle repair shop looks like a pretty decent draft of DDD specification with enormous list of source traces and open decisions. Can’t spot the silent assumptions so far, need further inspection. But hitting the wall of single run in one step and no my Abra Kadabra stuff (task decomposition with parallel processing), need better tooling, something like surrealdb+surrealism extensions to make it active graph with reasoner. Even pro collapses under task complexity if given it as a whole.