Don’t Protect Your Domain from Legacy Systems at All Cost

For the past 9 months, I have been working on a project related to proper VAT tax handling at zooplus. If I were to name a single biggest lesson learned during the course of this project, there’s a big chance that it’d be about taking a more legacy-friendly approach to domain modeling.

Our Approach

I wasn’t working on the project since its very beginning, so I don’t know whether that was planned, but our approach to handling the “legacy” stuff effectively turned out to be like this:

  • the parts of the “legacy” domain model that other systems realistically should not depend on are to be destroyed, burned, forgotten etc. Ultimately, they are to be replaced by a new, shiny domain model of ours
  • the parts of the “legacy” domain model that other systems need to depend on (for a good reason ofc.) are to be supported by translating requests from the “legacy” language to our new and shiny one

Sounds good, doesn’t it? I mean, really. You dump whatever you can realistically dump and provide a “thin” translation layer that both allows you to keep your domain clean and allows the clients to use your service in the way they expect it to be used – “win-win”.

You probably noticed a lot of double quotes in the previous sentences and it’s high time I explained why I’ve decided to put so many of those.

Misdefined Legacy

Although all of the above sounds good in theory and it probably could work in some cases, it was not our case. Why? Because we took a way too broad definition of what “legacy” is.

(There might be a lot of “we” in this post, while it actually means “Myself and I hope my teammates agree”.)

We basically treated every single term and concept that came from the old system as “legacy” and replaced it with one that better fits our mental model. As obvious as it sounds when I write this now, we completely didn’t take into account that not every single concept from the old systems is “legacy” that you need protection from!

On the contrary, there’s a plethora of important domain knowledge in there. Also, in software-driven companies like ours, that model was an exact description of how the business operated at that time. Discarding all that was like saying that every single thing related to VAT was wrong in the past and required a rework. That was not our case and I doubt it ever was to anyone.

Of course, there will be things that are entirely wrong and should be kept out of the new models or ones that seem correct but do not fit in the new project vision. But almost always there also will be things that are entrenched deep in a company’s core and you won’t manage to get away from them. Even if you try, they will keep coming back to bite you every single time.

The Bite

This obvious mistake has already shown itself on the code level. At least three important terms, that I’d now surely put into our domain model, were pushed away to the translation layer instead. This turned our vision of a “thin” translation layer into a little monstrosity that’s hard to test, read, and generally reason about.

On the other hand, our actual “domain model” seems a bit simplistic at this point. Since the complexity was located elsewhere, it boils down to a few related classes and a couple business-related algorithms. So far, we took away its chance to really shine.

Next Steps

In our case, the consequences are not so bad. I mean, the project is thoroughly tested, so we probably won’t fear to take a swing and refactor things at one point. But that does not mean that the lesson here is not important. IMHO, we got lucky, both because the project is so small and because we had/have enough time to recognize and fix the mistake. Will we get so lucky next time? Will you be so lucky? I’d rather not check, so let’s both learn the lesson from my mistake:

Not every single thing in old software is a legacy that must die. Old systems are often the way the business operates and we should strive to fit into them nicely instead of protecting our “new, better” ideas at all cost.

Good luck! 🙂

About the Author Grzegorz Ziemoński

King of Tidy Java, nerd that thinks about producing perfect software all the time and proud owner of 2 cats.

follow me on:
  • Szymon Janikowski

    That reminds me of Eric Evans’s talk “Good Design is an imperfect design” from DDDExchange and DDD Europe this year. Among many other topics he talks there about the respect which (some? many?) legacy systems deserve 😉