Hi, I'm Nico,
I am a senior engineer for a ticket broker business based in London (UK).
You're reading From the office!
This is a daily (almost) posting routine in which I journal about the tech I work on during my day-to-day life in the office.
Who is this post for?
Here we talk about DDD, design patterns, and the Anti-Corruption Layer. if you are not quite there yet you might start with:
https://anastasionico.uk/blog/learn-php
https://anastasionico.uk/blog/domain-driven-design-quickest-the-basics
The problem
As a kid, I used to love wondering about and exploring every old room when I was visiting my grandmother's house.
It was not so rare to find, among those old boxes, letters, and yellowed newspapers, amazing discoveries.
Especially from the eyes of a 5 years old kid.
I still remember quite vividly the one time I came across an odd-shaped brass joypad with numbers on its side and a date engraved on the bottom.
13/04/1925
As you might have already understood, despite being made of metal its rest came to an end quite quickly, and in just a few minutes that thing was split apart into many pieces.
More often than not, many of these antiques are so delicate that it is smart to just leave them alone and limit my watching them.
Today, things have changed and the situation is not quite the same, but, for certain expect. I felt the same vibe.
In fact, I am currently refactoring a ~10 years old API into something more modern and I must say, the task does not lack challenges.
Like the ones of you that have worked on legacy code, The sensation of wander and astonishment hit me multiple times a day.
Usually, they are accompanied by vivid exclamations like:
***Who the heck wrote this?
Why on earth there is this loop here?
What am I doing with my life?***
Luckily it is not 1925 anymore and people have developed many great strategies and patterns that help us not break down our code like an old brass phone.
As I learned at a young age, sometimes, It is smarter to leave stuff alone.
Domain-driven design
One of those brilliant people I was mentioning above is surely Eric Evans.
He is an author and came up with the DDD idea.
What is DDD?
Imagine a phone.
A phone is not just a set of metal and plastic things, I phone was someone's dream, the concept of being able to communicate from far away.
It has been molded with the best shape possible to do what it does and has much different functionality that must work in sync to make a call possible.
Evans explains that the code should not be seen as files containing symbols.
It is more than that.
When beginning to code we should focus on what the main goal, dream, and purpose are.
What domain this does code need to operate in?
Once we fully understand that we can be sure to code the right thing and not introduce errors inside the codebase
Preserving integrity
When multiple teams work on the same codebase or, like in my case, when we deal with very old code that is easily breakable, specific care needs to be taken in not breaking what is working.
Delicate is not synonymous with broken and, chance are, something 10 years old has already made his way to become the core of the business.
A critical error during refactoring the session domain, or customers, or orders, and a big chunk of the revenues can go away is a snap of the finger.
Bringing with them several people working within the company.
In my opinion, the domain is also this.
So, how do we preserve delicate code?
Anti Corruption Layer
Listen up,
The majority of applications out there have been developed without using proper separate models, if then often the model is cumbersome and confused.
Sometimes these models have been so integrated with the system that is better don't touch them at all and keep them outside.
This is another challenge when working with legacy code.
An Anti-Corruption Layer is a layer (it can be a package, a class, or an entire system) that lives in between our client and the external application.
This layer has to be still considered a full part of the DDD architecture of the domain.
Its role is to be a translator between the two different domains
How do you implement it?
The Anti Corruption Layer should be seen as a service from the client model.
If considered a service it will be very easy to consume while laying in between the two.
The service will do the translation and our model remain insulated.
The way this layer is formed is by using a facade for each domain it is translating this facade then, in order to be consumed needs an adapter that can use it.
If, like in my case you have many different domains in your legacy code. you will need many facades that connect to it, also each facade needs to be 'adapted' with its own adapter to avoid clutter and multi-reponsibility.
What is your take?
Have you ever used an Anti-Corruption Layer?
What was your experience writing that?
Write your thought in the comment below.
Conclusion
I have been a web developer for almost a decade now.
Working with world-class businesses and award-winning marketing agencies situated in the heart of London.
Also, I write articles and tutorials on my blog and online communities and help businesses build their presence online.
Top comments (5)
Do you like this story-like content or prefer going straight to the point?
I like to write "story-like" content myself, because it's a nice way to reflect, connect the dots, add context. I assume nobody cares, so if I have a solution to a problem at the end of a convoluted personal story, I just add a TL;DR link at the beginning so a potential reader can jump right there.
thanks for the feedback TL;DR would be a great addition.
How long have you been writing?
I've been writing for a long time, on different topics (mostly music and art), but it's all self-taught. I guess there is a lot to improve :).
That is great! keep on going!