Domain-Driven Design (Eric Evans, 2003) has had a resurgence with microservices. The aggregate, bounded context, and ubiquitous language concepts provide vocabulary and structure for microservices decomposition. What actually works in practice differs from the ideal in the blue book.
Bounded contexts as team boundaries
The most practically useful DDD concept for microservices is the bounded context: a clear linguistic and data boundary within which a model is consistent. A bounded context maps well to a microservice or a small group of tightly related microservices. Team Topologies aligns with DDD here: stream-aligned teams own their bounded contexts. The bounded context makes explicit what each team owns and what the interfaces between contexts are.
Ubiquitous language as communication infrastructure
The ubiquitous language concept, a shared vocabulary between developers and domain experts used in code, tests, discussions, and documentation, is the highest-leverage DDD practice for most teams. The investment is small (workshops to define the language, code review to enforce it) and the payoff is large: reduced translation cost between business requirements and code, fewer misunderstandings in requirements sessions, code that is readable by domain experts.
Strategic vs tactical DDD
Strategic DDD (bounded contexts, context maps, core domain identification) is widely applicable. Tactical DDD (aggregates, entities, value objects, domain events, repositories) adds significant design complexity that is not justified for every application. The aggregate pattern in particular, ensuring transactional consistency within an aggregate and eventual consistency across aggregates, is the right model for complex, collaborative domains but adds overhead for simpler CRUD applications.
The modelling investment
DDD requires sustained investment in domain modelling: workshops with domain experts, EventStorming sessions to map domain events and commands, context mapping sessions to define bounded context interactions. Organisations that skip this investment and apply DDD patterns to a domain they do not thoroughly understand produce models that reflect the database schema rather than the domain. The pattern application without the modelling investment produces complexity without the design clarity.