# Automating Domain-Driven Design: Experience with a Prompting Framework

arXiv: https://arxiv.org/abs/2603.26244 · HTML: https://mlsanity.com/paper/2603.26244/

## Key facts

- No citing papers in the map yet (data through 14 Oct 2026).
- Builds on 8 of its 17 references that are in the map.
- First posted on arXiv 27 Mar 2026.

## Builds on (most cited first, 8 of 8)

- [The Prompt Report: A Systematic Survey of Prompt Engineering Techniques](https://mlsanity.com/paper/2406.06608/) (2024)
- [Generative AI for Software Architecture. Applications, Challenges, and Future Directions](https://mlsanity.com/paper/2503.13310/) (2025)
- [On the use of Large Language Models in Model-Driven Engineering](https://mlsanity.com/paper/2410.17370/) (2024)
- [DRAFT-ing Architectural Design Decisions using LLMs](https://mlsanity.com/paper/2504.08207/) (2025)
- [On the Utility of Domain Modeling Assistance with Large Language Models](https://mlsanity.com/paper/2410.12577/) (2024)
- [Domain-Driven Design in Software Development: A Systematic Literature Review on Implementation, Challenges, and Effectiveness](https://mlsanity.com/paper/2310.01905/) (2023)
- [An LLM-assisted approach to designing software architectures using ADD](https://mlsanity.com/paper/2506.22688/) (2025)
- [ARLO: A Tailorable Approach for Transforming Natural Language Software Requirements into Architecture using LLMs](https://mlsanity.com/paper/2504.06143/) (2025)

## Abstract (arXiv)

Domain-driven design (DDD) is a powerful design technique for architecting complex software systems. This paper introduces a prompting framework that automates core DDD activities through structured large language model (LLM) interactions. We decompose DDD into five sequential steps: (1) establishing an ubiquitous language, (2) simulating event storming, (3) identifying bounded contexts, (4) designing aggregates, and (5) mapping to technical architecture. In a case study, we validated the prompting framework against real-world requirements from FTAPI's enterprise platform. While the first steps consistently generate valuable and usable artifacts, later steps show how minor errors or inaccuracies can propagate and accumulate. Overall, the framework excels as a collaborative sparring partner for building actionable documentation, such as glossaries and context maps, but not for full automation. This allows the experts to concentrate their discussion on the critical trade-offs. In our evaluation, Steps 1 to 3 worked well, but the accumulated errors rendered the artifacts generated from Steps 4 and 5 impractical. Our findings show that LLMs can enhance, but not replace, architectural expertise, offering a practical tool to reduce the effort and overhead of DDD while preserving human-centric decision-making.