Birbla

Join the discussion

Write your take first — we'll ask for email only when you're ready to publish.

Sign in
  • Hacker News
  • > The issues are then addressed by my AI system based on skills and sub-agents.

    So I don't think this is really the way to go imo. Relying on AI can increase productivity but it's extremely hard to manifest.

    by ydna404
  • When asked about DDD at a job interview I joked it was Debug Driven Development, when you start with empty directory and file the first bug "The app doesn't do anything. It should ..."

    Non-ironically that's pretty much the way I work with AI agents now.

    by scotty79
  • i'm sorry to say that besides like the first paragraph, this article is mostly ai slop. i thought that we mostly weren't allowing ai written content on hn? (@dang whats the policy here?)

    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

    by theahura
  • Well, I think this idea is pretty cool — it feels very similar to Matt's domain-modeling: https://github.com/mattpocock/skills/blob/main/skills/engine..."
    by adltereturn
  • I completely agree. At the early stage of service development I was recently in charge of Judging that this service will clearly continue to be domain-advanced I have refactored everything using DDD patterns. And as expected, the service rules are becoming more and more complex, but thanks to the well-prepared bounded context boundary definitions and Ubiqutous language definitions at the start, it hasn’t gotten messy and Claude is still developing it.

    The cost of writing code is now converging to zero, but Communicating with people and setting precise boundaries and language settings for the service is I believe that it is still an extremely remain role for developers.

    My concern is that none of our services have applied the DDD pattern. I can’t even refactor the existing legacies If they could build the service again, they would have strongly insisted that everything be built using DDD patterns...

    I look forward to the next article.

    by kimseungyong
  • Something i read in the earlier paragraphs about llms being easier to work with in greenfield projects…

    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

    by owaiswiz
  • I've also been a little-d DDD fan, and we've had luck with per-entity `md` files to language-independent document domain behavior/quirks/usages.

    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.

    by stephen

Explore Birbla archives