The first step is understanding the system. Making domains visible, identifying dependencies, and building a shared understanding between business and IT.
But this is where the real challenge begins.
A domain model alone does not change anything. It creates transparency, but not decisions. The key question is therefore: how do you turn this understanding into a concrete, manageable modernization effort?
From understanding to prioritization
A structured domain model reveals how a system is organized from a business perspective. It shows which areas exist, how they interact, and where complexity emerges.
What initially appears to be a purely analytical exercise quickly becomes the foundation for prioritization. As transparency increases, it becomes clear that not all parts of the system are equally relevant.
Some domains are closely tied to the core business and directly influence competitiveness. Others serve supporting functions or have evolved historically without providing significant value today.
Without this differentiation, typical problems arise. Teams work in parallel without a shared direction. Resources are distributed without a clear understanding of where they create the most impact. Modernization becomes a collection of isolated initiatives rather than a coordinated transformation.
Systematically evaluating domains—based on factors such as business relevance, change pressure, and technical complexity—creates a solid basis for decision-making.
Dependencies as a key control factor
In addition to the importance of individual domains, their dependencies play a central role. In long-lived systems, these dependencies are often implicit, historically evolved, and rarely fully documented.
Yet they are one of the main factors that determine what is actually feasible.
In the project, it became clear that seemingly isolated changes often had unexpected effects on other parts of the system. Functions that appeared independent were tightly coupled, either technically or from a business perspective.
Only by making these dependencies explicit did a realistic picture emerge.
Dependencies are not purely technical. They often reflect business relationships and are closely tied to how processes are structured within the organization.
Without this understanding, planning remains speculative. With it, planning becomes reliable.
Why sequencing matters more than target architectures
Modernization efforts often focus heavily on target architectures. Future system landscapes are designed, technologies are selected, and structures are defined.
While these target states are important, they are not sufficient.
The key question is not only what the system should look like, but how to get there.
In complex systems, the sequence of changes is often more important than the desired end state. A technically sound target architecture may be impossible to implement if it ignores existing dependencies.
In the project, it became clear that certain domains first needed to be stabilized or decoupled before others could be modernized effectively.
Modernization thus becomes a sequence of interdependent decisions, rather than a single design exercise.
Migration strategies as deliberate choices
Based on domain understanding and dependency analysis, different migration strategies can be derived. These are not abstract concepts, but direct consequences of the system’s structure.
In some cases, it makes sense to refactor existing components incrementally. In others, a clear separation and reimplementation of specific domains is the better approach. Some areas can be stabilized and deliberately left unchanged for the time being.
The key is that these decisions are not driven by technology, but by business context.
Every strategy involves trade-offs between risk, speed, and effort. Without a clear understanding of the domains, these trade-offs cannot be evaluated properly.
Transformation as a structured process
A useful concept in this context is organizing modernization into clearly defined transformation units, often referred to as “waves.”
Instead of defining a single large, hard-to-control program, modernization is broken down into sequential phases. Each phase focuses on selected domains, considers their dependencies, and delivers a concrete outcome.
This approach makes progress visible while allowing for flexibility as new insights emerge.
It reduces risk by avoiding large-scale simultaneous changes and enables teams to learn from each step and adapt accordingly.
From analysis to roadmap
The combination of domain model, evaluation, and dependency analysis ultimately results in a roadmap that goes beyond simple planning.
It does not only describe what should be done, but also why a particular sequence makes sense.
This fundamentally changes the role of the roadmap. It becomes not a static target state, but a tool for continuous decision-making.
Conclusion
Domain-Driven Design does not provide the solution to IT modernization. It provides the foundation for developing meaningful solutions.
Only with a clear understanding of domains and their relationships do priorities become visible, dependencies understandable, and decisions traceable.
Modernization does not become easy.
But it becomes manageable.
Outlook
With a structured roadmap in place, the foundation for implementation is established. However, this phase introduces a new challenge:
How can existing systems be changed without compromising their stability?
And what role do approaches such as Golden Master Testing or the Strangler Fig Pattern play in this process?
This is what the next articles will explore.
