Building Modular Systems Before It Was Cool

Before "microservices" became a buzzword, before every company rushed to componentise their monoliths, I was learning the hard way why modularity mattered. My journey into modular thinking began not from a trendy conference talk or a best-selling tech book, but from dealing with real-world pain points—duplicated logic, brittle systems, and tangled dependencies.

While working at Lyons Davidson Solicitors, I encountered a sprawling codebase built with Silverlight, WCF, and ASP.NET MVC. On the surface, it was just another enterprise application. But under the hood, there were inefficiencies everywhere—particularly in how shared logic was handled. It wasn’t just that the same code was repeated in different places, it was that any change risked breaking something you didn’t even know was connected.

Instead of accepting this as the status quo, I started building shared packages that could be reused across Silverlight components. I centralised authorisation logic, abstracted repeated database access patterns using reflection, and reduced duplication wherever I could. At the time, it wasn’t called framework development. I just saw it as making things better for my future self and my team.

In retrospect, what I was really doing was laying the foundation for modular thinking. These Silverlight applications were more than just projects—they were components within a much larger system. That realisation became the guiding principle in how I approached architecture from that point forward.

Later in my career, particularly at SpaSpace and LMS, I leaned heavily into microservice architecture. Each domain was modelled as its own service with clearly defined boundaries and communication contracts. But the seed for that approach had been planted years earlier. Working on those Silverlight applications taught me the importance of encapsulation, contract-driven design, and the developer experience of consuming—not just writing—code.

What’s fascinating is how front-end componentisation influenced my back-end architectural thinking. Seeing how powerful it was to isolate and reuse visual elements naturally led me to explore how the same could be achieved on the service layer. To this day, I still champion modularity as a default mindset—not because it’s fashionable, but because I’ve seen first-hand the mess that results when you ignore it.

So while the industry has since caught up with buzzwords like "micro frontends" and "modular monoliths," I take pride in having fought those battles before the naming conventions existed. Modularity isn’t just a design choice; it’s a philosophy—one that continues to shape every system I build.