DRY = Don’t repeat yourself

  • hono4kami@piefed.socialOP
    link
    fedilink
    English
    arrow-up
    6
    ·
    15 days ago

    IMO, this is where techniques like Domain-Driven Design really shine as they put the business concepts at the forefront of things.

    Do you have a resource on where to learn DDD? I feel like I never understood the concept well.

    • JonC@programming.dev
      link
      fedilink
      English
      arrow-up
      5
      ·
      15 days ago

      As already mentioned, the blue book by Evic Evans is a good reference, but it’s a ittle dry. Vaughn Vernon has a book, “Implementing Domain-Driven Design” that is a little easier to get into.

      Personally, I found that I only really grokked it when I worked on a project that used event-sourcing a few years back. When you don’t have the crutch of just doing CRUD with a relational database, you’re forced to think about business workflows - and that’s really the key to properly understanding Domain-Driven Design.

      • vulture_god@lemmy.dbzer0.com
        link
        fedilink
        arrow-up
        2
        ·
        15 days ago

        Yeah for me the understanding really came when working in a federated GraphQL API. Each team had us own little slice of overall object graph, and overlap / duplication / confusing objects across the whole domain were a lot easier to see in that environment.