AI-Assisted DDD (Without Asking Anyone)

People often treat DDD as all-or-nothing: either you do “the full thing”, or you don’t do it at all. ¯\_(ツ)_/¯

And that’s one of the main reasons many teams never start.

Because “the full thing” usually sounds like a strategic redesign, a series of workshops, a calendar full of meetings — and a request for permission that will bounce around for weeks.

But DDD can be an evolution.

And you can start that evolution today, with tiny steps that don’t require a revolution plan or a committee sign-off.

A weekend experiment

Over the weekend I created a small GitHub repo:

https://github.com/pwyczes/ddd-ai-skills-applied

A library of skills for AI coding agents. They’re importable rulesets that turn “help me code” into “apply this pattern, this way, with tests”.

The goal is simple: Make “how we do DDD” portable across tools.

Because the problem is not that the AI can’t generate code.

The problem is that it will happily generate your codebase into a slightly different codebase — unless you give it rules.

Why tactical patterns first (and what I’m not claiming)

If you want the biggest boost from DDD, you typically get it from strategic design. Bounded Contexts. Integration boundaries. Ubiquitous language. Real collaboration. That’s the heavy machinery. 

It’s also expensive.

It takes time, alignment, facilitation skills, and usually more than one person pushing it through. (Believe me, I've been that person more than once.)

So here’s my pragmatic take: Start with something small, actionable, and low-risk — from day 0. Then iterate.

Tactical patterns won’t replace strategic design. But they can raise the baseline immediately, even in codebases that are not “doing DDD”.

The two skills: Value Object + Factory

This repo currently focuses on two tactical patterns that are almost unfairly useful:

1) Value Object SKILL.MD

Value Objects are not “DDD ceremony”. They are a way to stop leaking primitives everywhere and start expressing intent in your code.

They help you move from “everything is a String/int/BigDecimal” to “this value means something”

They force you (and the AI) to put meaning into types: immutability, clear construction, explicit equality rules, and behavior that belongs with the value — instead of scattering it across services and methods.

In practice,
Value Objects are one of the fastest ways
to reduce accidental complexity
without touching your architecture.

2) Factory SKILL.MD

Factories are not just “a pattern for hiding new()”. A good Factory makes object creation consistent, test-friendly, and boring in the best possible way.

It gives you one place where construction happens, where defaults live, where variations are named, and where tests can create objects without copy-pasting half a constructor call across the suite.

If you’ve ever seen tests that spend more effort constructing objects than testing behavior — you already know why this matters.

And yes: both of these patterns work even if your codebase has zero strategic DDD. No Bounded Context map required. No “domain model rewrite”.

Just small steps.

The pitch: DDD without permission

This is the part I like most.

You can take a tiny slice of your code — one concept, one hotspot, one ugly “primitive soup” — and improve it locally.

No migration plan. No months of refactoring. No permission.

Just:

• pick one “value” that deserves a type,

• introduce a Value Object,

• centralize creation through a Factory,

• add a few focused tests,

• move on.

That’s it. This is how evolution starts.

How to use it (quick start)

The workflow is intentionally simple:

1. Put the repo (or just the skill folder) somewhere your agent can read from. 

2. Open the relevant SKILL.md.

3. Tell the agent: “Follow this skill. Apply it here. Tests included.”

You’ll get more value if you give the agent the same three inputs I describe in the README:

• Context (language, frameworks, constraints)

• Target (what exactly to build/change)

• Definition of done (tests, edge cases, style expectations)
  

What a “tiny step” looks like

You don’t need to start with “the domain”.

Start with something mundane:
EmailAddress, Money, Percentage, TimeRange, Coordinates, etc.

Pick one. Make it a Value Object. Then introduce a Factory where object creation is messy, duplicated, or hard to test.

You’ll feel the difference fast.

Not because the code suddenly becomes “DDD compliant”. But because it becomes more explicit, more stable, and easier to reason about.

If it helps, share it with a friend, and give me a quick signal that you used it.

I’m going to iterate on this repo either way — but it’s always good to know what landed and what didn’t.