In order to provide a general overview of the strategical side of Domain-Driven Design, we'll use an approach from Jimmy Nilsson's book, Applying Domain-Driven Design and Patterns. Consider two different spaces: the problem space and the solution space.
In the problem space, Domain-Driven Design uses Domains and Subdomains to group and organize what companies want to solve. In the case of an Online Travel Agency (OTA), the problem is about dealing with things like flight tickets and booking hotels. Such a Domain can be organized into different Subdomains such as Pricing, Inventory, User Management, and so on.
In the solution space, Domain-Driven Design provides two patterns: Bounded Contexts and Context Maps. The goal is to define how to provide an implementation to all the identified Subdomains by defining their interactions and the details of those interactions. Continuing with the OTA example, each of the Subdomains will be solved with a Bounded Context implementation — for example, consider a custom Web Application developed by a team for the Pricing Management Subdomain, and an off-the-shelf solution for the User Management Subdomain. The Context Map will show how each Bounded Context is related to the rest. Inside the Context Map, we can see what type of relation two Bounded Contexts have (example: customer-supplier, partners). The ideal approach is to have each Subdomain implemented by one Bounded Context, but that's not always possible. In terms of implementation, when following Domain-Driven Design, you'll end up with distributed architectures. As you may already know, distributed architectures are more complex than monolithic ones, so why is this approach interesting, especially for big and complex companies? Is it really worth it? Well, it is.
Distributed architectures are proven to increase overall company productivity because they define boundaries for your product that can be developed by focused teams.
If your Domain — the problem you need to solve — is not complex, applying the strategical part of Domain-Driven Design can add unnecessary overhead and slow down your development speed.
If you want to know more about the strategical part of Domain-Driven Design, you should take a look at the first three chapters of Vaughn Vernon's book, Implementing Domain-Driven Design, or the book Domain-Driven Design: Tackling Complexity in the Heart of Software by Eric Evans, both of which specifically focus on this aspect.
