Domain-driven design (DDD) is too often mistaken for just having an object-oriented model that mimics the behavior of the business domain. Not that having such a model is wrong or out of place; it’s just that there’s much more than that in DDD. DDD is primarily a method for understanding and managing the complexity of monumentally large and rich domains. In similar situations, a faithful domain model is not just appropriate but a true lifesaver. In all other (more common) situations, the value of DDD lies elsewhere and overall DDD is much closer to the idea of microservices and CQRS than domain modeling and O/RM frameworks. To make its point the workshop is based on four modules. First, it discusses common patterns for implementing the business logic and relates them to data access and layered architectures. It then introduces the value of keeping command and query stacks separated and how the persistence patterns that best fit. Finally, we expand on the DDD patterns of domain analysis (ubiquitous language and bounded context) and reach the territory of microservices and issues and opportunities available there.