Why should someone care about about legacy systems?

Legacy systems are usually what runs the business of the company. They are often at the heart of the business. Therefore changes to them might are important to support the business. But they are often hard to change or are built with a business in mind that is actually outdated. So working on them is probably more important than working on greenfield projects – legacy represents the existing business.

What is the relation between domain-driven design (DDD) and legacy software?

Domain-driven design gives us many approaches to architect systems — in the large with strategic design and in the small with tactical design. However, legacy systems already have an architecture and usually that architecture is not too great. So at first sight it seems that DDD can only show what the architecture could look like in an ideal word. However, the more important challenge is to apply DDD principles in the real world to the existing code. That code is usually hard to understand and change. And these constraints of legacy systems often have a huge impact on what the architecture looks like in the end and how they differ from an ideal architecture.

What sparked the interest in this subject?

Dealing with legacy systems is a very common problem that many of my clients have. So approaches in this field are very valuable to me and my clients. Also, DDD is a toolbox that includes patterns for code, architecture, and also analysis. I was always fascinated by the variety of patterns and the knowledge they represent. And there are also quite a few tools that tackle challenges with legacy system on so diverse levels like code and overall business strategy. So I found it very valuable and fascinating to look into these concepts and apply them.

Would you rather use DDD to design new systems or improve a legacy system?

Actually I would rather deal with legacy systems. I think it poses more interesting challenges — and I enjoy these kinds of challenges. Legacy systems introduce all kinds of constraints. Also a legacy system is a successful system — otherwise nobody would want to change and improve it despite the challenges. So the work on a legacy system is practically guaranteed to solve important problems and really have an impact.

What is the most important point when applying DDD to legacy systems?

Legacy systems are usually hard to change. So you have to decide what you do about that. One way is to actually change the architecture and introduce DDD’s bounded contexts. This can be done in a number of ways – extracting bounded contexts or building bubble contexts inside the legacy system. Another way is to focus more on understanding the business first and figuring out how to best support the business with changes to the legacy system. At the end, domain-driven is all about supporting the business. But this is more than decisions about the architecture — it is also about figuring out which business requirements matter for the architecture.