Software architecture is one of the most difficult technical discussion among fellow developers. Simply because there is no right or wrong answer in most cases. It seems to always depend. What's the best way to architect a client-server application to handle millions of live transactions with zero downtime? Ok, I hope the answer is clear in this case; it depends. What I want to discuss in this article is a generalized approach I've recently been using to access software architecture quality. Its all about namespaces and references.
Architecture is about drawing boxes around code blocks and adding lines to connect them. Its quality is determined by those connections. In programming terms, these boxes are typically referred to as namespaces or packages depending on the language in use. Then, of course, we create connectors by adding references. When building enterprise level applications, this I have found to be very crucial. The act of designing namespaces and their corresponding references is what I call software architecture.
So how do you draw these lines, you may wonder. I tend to think about it by looking at what to keep out with the goal of holding my connectors at minimal. Another characteristic I use is grouping code block by their anticipated change frequency. Things that change very frequently are isolated from those that tend to remain stable. Also, those that change for related reasons are kept in proximity. At the end of the day, it all depends but this I highly encourage you to bear in mind.
Top comments (1)
Pretty succinct definition. At the simplest terms I've come to view it simply as a big picture overview of a software system. You look at how at the pieces, the details of those pieces, and how they relate to other pieces.
Do you have any good reads on software architecture?