Anyone preaches the virtues and advantages of domain-driven design, its positive impact on maintainability and adding features, and how it improves developer experience. However, as all things in life, all roses have their thorns.

Has anyone had any negative experience caused directly or indirectly by domain-driven design? This might be a botched migration, problems during the requirements gathering stage, domain models ending up being too rigid/too permissive for an application, etc.

  • douglasg14b@programming.dev
    link
    fedilink
    English
    arrow-up
    4
    ·
    edit-2
    1 year ago

    Like most large conceptual practices the pain comes when it misused, mismanaged, and misunderstood.

    DDD like Agile, when applied as intended, adds more to success than it detracts. This means that others take it and try to use it as a panacea, and inappropriately apply their limited and misunderstood bastardization of it, having the opposite effect.

    Which leads to devs incorrectly associating these concepts & processes to the pain they have, instead of recognizing a bad implementation as a bad implementation.

    Personally, I’ve found great success by applying DDD where necessary and as needed, modifying it to best fit my needs. (Emphasis mine). I write code with fewer bugs, which is more easily understood, that enforces patterns & separations that improve productivity, faster than I ever have before. This is not because I “went DDD”, it’s because I bought the blue book, read it, and then cherry picked out the parts that work well for my use cases.

    And that’s the crux of it. Every team, every application, every job is different. And that difference requires a modified approach that takes DevX & ergonomics into consideration. There is no one-size-fits-all solution, it ALWAYS needs to be picked at and adjusted.


    To answer your question

    Yes, I have had lots of pain from DDD. However, following the principals of pain driven development, when that pain arises we reflect, and then change our approach to reduce or eliminate that pain.

    Pain is unavoidable, it’s how you deal with it that matters. Do you double down and make it worse, or do you stop, reflect, fix the pain, refactor, and move on with an improved and more enlightened process?

    It’s literally just “agile”, but for developer experience.

    • lysdexic@programming.devOP
      link
      fedilink
      English
      arrow-up
      1
      ·
      1 year ago

      Yes, I have had lots of pain from DDD. However, following the principals of pain driven development, when that pain arises we reflect, and then change our approach to reduce or eliminate that pain.

      I was hoping that this discussion would lead to people sharing their personal experience to allow others to benefit from that reflection.