Heuristics
Accept Imperfect Boundaries in Legacy Decomposition
How should you approach defining team boundaries when migrating a legacy monolith?
When applying DDD to a legacy system, accept that the initial boundaries will be imperfect and ‘not pretty.’ The goal is to create a starting point for team autonomy, even if it requires pragmatic compromises on architectural purity. These boundaries can be refined over time.
Example
To move away from a legacy application, the architecture was ‘chopped up’ into a context map. The team accepted that the initial boundaries were not good, but they were a necessary first step.
Discussed in
