Getting started with DDD when surrounded by Legacy systems
STRATEGY 1: BUBBLE CONTEXT(Part 1 of a series by Eric Evans)
- Why we need the bubble
- How we form the bubble
- What becomes of the bubble
We say that effectively applying the tactical techniques of domain-driven design (DDD) requires a clean, bounded context (See September 2010 newsletter). This can be a daunting requirement when your work is dominated by legacy systems. These systems are often tangled, and even when they are orderly they are usually not suited to DDD. In a series of articles over the next few months, I'll describe strategies for getting started with DDD when you have a big commitment to legacy systems.
All of these strategies will be ways of establishing a new bounded context. Attempts to employ the DDD tactics in the context of a legacy system almost always disappoint. One of the fundamentals of DDD is that we choose a model (by which we mean a system of abstractions) well suited to the problem at hand, yet a legacy system already has an established model, albeit implicit, and this model can seldom be changed with a reasonable amount of effort. Even if the legacy model could be changed, the new model might not suit the legacy functionality -- the change could undermine what the legacy system was always good at. On the other hand, simply adding objects that express a distinct model without changing the ones already there will lead to conflicting rules and concepts.
No comments:
Post a Comment