Domain-driven (re)design: Rejuvenating a forty-year-old legacy system

Imagine the eighties. General-purpose 3GLs (third-generation programming languages), such as C and COBOL, are established. Domain-specific 4GLs (fourth-generation), such as Oracle Forms, are emerging.

One of the companies we work with decided to build its own 4GL system. Fully tailored to its business to improve productivity, it was DDD avant la lettre. A big success. And interestingly, after forty years of mission-critical usage, the 4GL system itself has become part of the very domain it was initially designed after: panels, screens, and input controls in the UI now influence the ubiquitous languages spoken by staff and contribute to the delineation of bounded contexts.

Over time, though, programmers come and go. Requirements change. Technical debt accumulates. Forty years down the road, the once-modern 4GL system is in need of rejuvenation. However, employing DDD tactics in the context of legacy systems is well-documented to be hard. For instance, in his paper "Getting Started with DDD when Surrounded by Legacy Systems", Eric Evans himself writes it "almost always disappoint[s]."

In this session, we share our experiences with the domain-driven (re)design of the forty-year-old 4GL system at our client. Topics covered include:

• domain analysis in the presence of an existing, normative legacy system
• rejuvenation roadmapping based on bounded contexts
• DSL design (not implementation; that's an interesting topic for another time) to represent and manage digital assets and domain knowledge.

We also compare our approach to the strategies described in Evans' aforementioned paper (and taught in the DDD Europe Academy workshop "DDD & Legacy Systems").