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.
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.
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.
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.