Not the person you're asking but thought I would chip in. Domain Driven Design has a lot of good ideas, but then I consistently see them misrepresented by othe

Not the person you're asking but thought I would chip in. Domain Driven Design has a lot of good ideas, but then I consistently see them misrepresented by others who seem to half-understand it? Probably the clearest example is the idea of a “bounded context.” You will find microservice folks for example who say you should decompose such that each microservice is one bounded context and vice versa, but then when they actually decompose a system there's like one microservice per entity kind (in SQL, this is a relation or table, so in a microservice pet-adoption app there would be a cat service, a dog service, a shelter service, an approval service, a user service...). The thing is, Eric Evans is pretty clear about what he means by bounded context, and in my words it is taking Tim Peters’s dictum “Namespaces are one honking great idea—let’s do more of those!” and applying it to business vocabulary. So the idea is that Assembly Designer Jerry on the 3rd floor means X when he says “a project,” but our pipefitter Alice on the shop floor means something different when she says “a project,” and whenever she hears Jerry talking about a project she is mentally translating that to the word “contract” which has an analogous meaning in her vocabulary. And DDD is saying we should carefully create a namespace boundary so that we can talk about “pipefitting projects” and “pipefitting contracts” and “assembly-design projects” and then have maybe a one-to-one relationship between pipefitting contracts and assembly-design projects. Eric Evans wants this so that when a pipefitter comes to us and tells us that there's a problem with “the project,” we immediately look at the pipefitter project and not the assembly-design project. He really hates that wasted effort that comes from the program not being implemented in vocabulary that closely matches the language of the business. So if the microservices folks actually had internalized Eric's point, then they would carve their microservices not around kinds of entities, but rather archetypes of users. So for the pet adoption center you would actually start with a shelter admin service and a prospective adopter service and a background checker service, assuming those are the three categories of people who need to interact with the pet adoption process. Or like for a college bursar's office you would decompose into a teacher service, student service, admin service, accountant service, financial aid worker service, person who reminds you that you haven't paid your bills yet service. So I thought it was a really good read, that's actually a really interesting perspective, right? But I don't think the ideas inside are communicated with enough clarity that I can bond with others who have read this book. It is kind of strange in that regard.