This is a small project that sprung out of the first large project I wrote for a large food producer. The company in question had very big and complex software solutions, and a lot of the business logic was more grown than designed. This led to a lot of confusion, and different teams interpreted the data and its rules differently, which led to subtle problems further down the line.
One area was particularly problematic, which is the article registry. In other words, the products this company produced. They had a large database with many, many different ways of expressing even simple things, like availability.
To make the problem even worse, the database was very slow. Fetching the thousand articles the system knew about would take around 20 minutes. Most systems needed this information available at all times, and quickly, so they all ended up developing their own caches and updating logic. Needless to say, none of the systems agreed on what the products were.
I resolved this issue by writing a glue service that would interpret the rules. Correctly this time. I wrote a plethora of tests to ensure that I was interpreting everything correctly, and I weeded out at least a few subtle bugs in every system using the articles. I also made the tests part of the service itself, so it could interpret the data and give detailed feedback on any errors. This is the part I'm most proud of, because it allowed my users to finally understand what had gone wrong. The service also stored a cache of all articles that would update automatically when the source material updated, so nobody needed their local caches anymore.
This simplified quite a few code bases, and was generally regarded as a big success.