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).
It is, if only to learn how some people approach modelling domains. It's rarely a bad idea to see different approaches to doing stuff. That being said Evan's book is a rather dry read.
A lot around DDD, like implementations tend to have become dated. However, the principles around a well designed domain isn't. So not sure what he refers to.
Works like from Rebbeca Wirfs-Brock, I believe it was called Object Design about roles, responsibility and interaction/collaboration is like just if not more important to me.
It boils down to, understanding the motivations behind a technology and apply when needed. Design your objects and software according to state, etc.
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).