Domain-Driven Agents
70 points - yesterday at 7:28 PM
SourceComments
I.e. an `Author.ts` has an `Author.md`, `Book.ts` has an `Book.md`.
For agents, we've given them a skill to read & write the `md` files:
https://github.com/joist-orm/joist-orm/blob/main/packages/co...
And so agent-written `md` updates are showing up in PRs. So far it seems useful (our main repo is a 350k LOC TypeScript monolith).
Admittedly, this is way less sophisticated (& less complicated) than the "graph of edges in/out of every bounded context" in the OP, but that is probably again my "little-d" DDD perference, where I find some of "DDD at scale" patterns lead to, imo, over-engineering.
My experience has been the opposite. They work well on existing projects but are not so great at new ones (unless you are just vibe coding something simple).
I think it has something to do with it being able to rely on years of established structure/conventions on existing projects that makes them better IME
aside from that, i think that this is overcomplicating a more basic idea. You should have agents that leave docs behind in your codebase, and those docs should be localized to the structure of your code, but you do not need any fancy format or manifest.
We've had a lot of success with having the agents write and maintain a docs.md file in each folder, and requiring that they both read and update that file whenever they make a change in that folder
Non-ironically that's pretty much the way I work with AI agents now.