| I'd put it much lower on the list of readings. Complex domains are still around, developers should learn them before trying to come up with solutions but they're implemented differently: As services with clear boundaries, with explicit contracts. DDD can be applied to the boundaries of services, within API contracts so they speak a common language. The unit of encapsulation of a service makes a lot of the implementation details in the book moot. Problems that are more relevant today are service discovery, observability, low friction of computing provisioning as organizations grow. This sounds a lot like devops concerns. It's not purely so. It's the complexity that grows when organizations expand and add functionality to their software. Its outcome, tremendous complexity, is what DDD tried to tame in 2004. To expand on the above: When we began switching to services as units of encapsulation, we implemented boundaries, contracts, kept business logic separate. Did we match the domain perfectly? Often not, but the API contracts between services is easier to enforce. At a high level a standard can be set on how we should speak a shared language. This is most of the benefits I took out of Evans book. It happened organically in the industry slowly. Localized, each service is easy to reason about, test, and refactor. Great. The complexity NOW is managing and operating these services for small to medium organizations (the same ones struggled with domain modeling and design patterns to tame their monolith in a previous era). |