Software Design – The Big Picture (Intro)

Most of my blog posts on software matters are about very specific, almost niche, subjects. I wanted to summarize a big picture however for a long time – some of the most important aspects at least.

Starting from a big picture is important – and slightly dangerous. Important because it helps avoid jumping to conclusions too early. Dangerous because we need to avoid getting trapped in astronaut diagram architecture. Let’s dive in and start with some high level but fundamental aspects of pretty much any non-trivial software system:

Structuring for Control Flow

Any kind of software system will have to process interactions (or requests) from users, or other systems, or from itself. Structuring for control flow is about how to structure your code as to most “usefully” check permissions, where to best implement data types of a given interface or protocol, where to implement the actual domain logic and how to update persistent state. This sounds bigger as it is and it can be nicely explained without going into implementation details.

Working with Persistent Data

While there are certainly applications that derive their value purely from solving some algorithmic problem, the vast majority of software systems we get in touch only exist to help us work with data (state) that represents some aspect of our reality and will live much longer that any specific system we use to access it. That is why data or domain modeling is hugely important and there is excellent literature abundantly available. So we will only look into how to be smart about accessing and updating persistent data.

Modularization

Modularization is one, if not the key method for controlling complexity in software design. It is a mystery to me why this is – I think – absurdly underrepresented in publications. My pet subject.

Distribution

Often abused as a mechanism of modularization, but in fact, a completely different subject. At some point you need to bring your code to execution. If you need to or want to run a distributed system, what are good reasons, not so good reason, and actually nonsense reason for accepting remote boundaries.

With the next posts we will look at each aspect in more details. Stay tuned!