Domain Driven Design has become a widely accepted, if not the preferred method of conceptualizing and implementing complex software systems.

But when we talk about aggregates, bounded contexts and ubiquitous language, we often only have the scope of a single application / system in mind: We analyze the business, and ideally use the results to implement a runnable domain core to build a product around.
In more complex domains, there can also be more than one: Subdomains and peripheral systems need to be included - a distributed system is the inevitable outcome.

Both these scenarios allow us to build solutions from the ground up -- lean, cost-effective and customized to the business needs. In some cases, we might have to integrate or replace one or more legacy applications in the process.
For all of this, DDD provides well-known patterns, frameworks and solutions.

But what if even a single business process involves an entire company, with complex hierarchies, sign-offs and auditing, reports, and data protection concerns? What if existing processes aren't isolated, but span a plethora of systems with acronym names, implemented decades ago, by authors long since retired? What if they were written in forgotten languages, without the slightest idea of DDD in mind? What if real-time events must co-exist with end-of-day batch processing and asynchronous file transfers? What if the company's usual IT project is planned and budgeted as "Connect SAP to CRM"; its purpose and business value all too often lost in translation?
This is the ugly reality of large corporate enterprises, all too often embedded in politics and a dysfunctional culture. And they _really_ need our help...

Starting with some real-life "war stories" and anti-patterns, I will show examples of how even in the most old-fashioned corporate setting, DDD principles, patterns and architecture can serve as a guiding light towards a better and more sustainable infrastructure, and fundamentally benefit not only IT departments, but the entire enterprise.