Domain-Driven Agents
LLMs often stumble when confronted with the tangled realities of legacy codebases, leading to incorrect assumptions and ineffective changes. This article proposes a structured methodology, marrying Domain-Driven Design principles with AI agents, to make 'brownfield' projects amenable to automated development. It outlines a strategic approach where humans define architectural intent and agents execute tactical coding tasks, offering a pragmatic solution to a ubiquitous software engineering challenge.
The Lowdown
The author explores the common frustration of using Large Language Models (LLMs) in established, legacy codebases. While LLMs excel in greenfield projects, their performance sharply declines in 'brownfield' environments riddled with technical debt, inconsistent naming, and implicit knowledge. The core argument is that the code is not ready for the LLM, rather than the LLM being the issue.
- The LLM-Legacy Code Problem: LLMs struggle with deeply nested legacy systems because they lack the clear, consistent context and ubiquitous language needed to make correct decisions, often inventing conflicting terminology or misapplying architectural patterns.
- Shifting Economics of Development: The author distinguishes between 'strategic' work (deciding what to change and why) and 'tactical' work (the mechanical execution of those changes). LLMs have dramatically reduced the cost and effort of tactical work, freeing human developers to focus on strategic decisions.
- Agent-Driven Workflow: The proposed system involves human engineers creating GitHub issues outlining strategic changes. AI agents, powered by 'skills' (reusable instruction sets) and 'sub-agents' (isolated model sessions), then implement these changes, generating pull requests for human review.
- Domain-Driven Design (DDD) Foundation: DDD is crucial for providing the necessary structure. It establishes a 'ubiquitous language' and 'bounded contexts', which act as a shared language for both humans and AI models, bridging the gap between business needs and technical implementation.
- Manifests and Context Maps: Each repository includes a
.workflow.jsonmanifest that defines its domain, bounded contexts, and relationships with other contexts. Crucially, aCONTEXT.mdwithin each context acts as a living glossary, ensuring precise, unambiguous terminology. - Automated Consistency Checks: A generator script aggregates these manifests to create a comprehensive context map. This system automatically flags disagreements between how different contexts declare their relationships (e.g., inbound vs. outbound), raising
DDDissues for human or agent resolution. - Next Steps: With the strategic layer (context map, glossaries) in place, the subsequent phase involves migrating individual contexts to proper DDD domain models, further empowering agents to understand and refactor the codebase effectively.
By systematically structuring the codebase using DDD principles, engineers can create an environment where LLMs can reliably perform tactical coding tasks, allowing human developers to concentrate on higher-level strategic planning and architectural oversight, thereby chipping away at technical debt more efficiently.