Domain Driven Design
I’ve been diving further into Domain Driven Design as I like the feel of it and see that I can consolidate more understanding - this is a draft I originally wrote at the start of September before the AI Engineering Conference - I’m posting now as it is very reletvant to work I’m doing on Formalising Goal Decomposition for Agents. The relevance is that it is a point where I saw failure. :)
I need to paraphase this as I do not recall who said it where, one of my favorite half memories is reading that
“Domain Modelling is itself the process of learning, you cannot know it all at the start, and should expect to update aspects at any stage of the product development”.
When I thought I was using a cut down version of it for the Self-Consistency agent the implementation made sense - whilst I cannot articulate errors in the thinking, I can articulate where it needs improving.
DDD feels correct for development with agents as you define a Ubiquitous Language. The Domain Model and how it happens data is appealing as well.
However I lost my way when moving to the Self-Reflection agent. I moved too quickly, drunk on the success I had with an ATDD approach to a VSCode plugin. Applying ATDD to what I had started simply did not work. The interaction with the agent was disfunctional. Irrational Performance Measure is the term I like to use, and with Claude it isn’t just irrational, it is unknowable!
Whilst looking at the Coding Agent issue I’ve circled back around on Bounded Contexts and the Problem and Solution Spaces.
It has left me questioning Martin Fowler’s definition of a Domain Model though! In short, how can Domains be modelled in code if they are part of the problem space and not the solution space?
Vaughn Vernon in his “Implementing Domain-Driven Design” book states
“the subdomains live in the problem space and the bounded contexts in the solution space”
Some good reading on Domain Driven Design: