I once had an interesting debate with fellow developers over a software performance concern, which prompted us to revisit our architecture. Some argued that we needed a new architecture and indeed some of that work was underway. I had raised a few concerns over some of the architectural decisions that had been made in the past when I first joined the team but for entirely different issues. My particular concerns centered on testability. More precisely, it was practically impossible to test the system without having everything connected. From the UI down to the database – everything had to be running.
The first architectural decision made was Angular. This clearly struck a chord in my spine as I wrestle the idea. I thought to myself, Angular is a detail. Moreover, a detail that ought to remain hidden from an architectural perspective. The architecture of a system shouldn’t deal with how it is delivered – in my view at least. It is almost like describing the architecture of a house by the types of bricks and cement used. To architect a system is to carefully draw boundaries around the various components that make up that system and connect them in a thoughtful manner, i.e manage dependencies, without revealing the details. The delivery mechanism is a detail.
But what about agile, you may ask? Didn't we abandon the idea of big upfront designs? Is this what I'm suggesting? The answer, of course, is no. Good architecture is revealed slowly over time as the system grows. It is not something that you and I can craft over the weekend and be set for the remained of the system's lifetime, but rather something fragile - Hence the idea of keeping details hidden. I find it helpful to think of what to keep out rather than what to include when dealing with architectural design. The more I can keep out, the better.