Software Architecture

"All architecture is design but not all design is architecture. Architecture represents the significant design decisions that shape a system, where significant is measured by cost of change."

- Grady Booch -

Essentially, he’s saying that the significant decisions are “architecture” and that everything else is “design”. In the real world, the distinction between architecture and design isn’t as clear-cut, but this definition does provide us with a basis to think about what might be significant (i.e. “architectural”) in our own software systems. For example, this could include:

• The shape of the system (e.g. client-server, web-based, native mobile client, distributed, asynchronous, etc)
• The structure of the software system (e.g. components, layers, interactions, etc)
• The choice of technologies (i.e. programming language, deployment platform, etc)
• The choice of frameworks (e.g. web MVC framework, persistence/ORM framework, etc)
• The choice of design approach/patterns (e.g. the approach to performance, scalability, availability, etc)

The architectural decisions are those that you can’t reverse without some degree of effort. Or, put simply, they’re the things that you’d find hard to refactor in an afternoon.

Vision

It’s about understanding what you need to build, creating a vision for building it and making the appropriate design decisions.

By comparing the traditionally designed system with the modern system we can get a better impression on the impact of our decisions:

Traditional systems

In traditionally designed information systems we tend to share same data structures across different features. This requires redesigning of the existing tables as we add new features to our system. It is this rework that is responsible for features costing more as the size of the whole system grows.

Modern (event-driven) systems

In event-driven systems we utilize Event Sourcing and CQRS patterns to flatten the cost curve. These two patterns are shaping the modern software design that is cost effective, maintainable and scalable.

Event Sourcing

CQRS unlocks Event Sourcing pattern. Event Sourcing mandates that the state change of the application isn't explicitly stored in the database as the new state (overwriting the previous state) but as a series of events. This way you don't loose any data/information. Everything that happened in the system is stored.

Information is far more valuable then the price of the storage.

CQRS

The view model is continuously updated to contain a certain representation of the current state, based on the events. This way, every feature in the workflow has its own view, keeping features independent and making the cost of additional features constant.

Structure

It’s about the decomposition of a product or project into a collection of components/modules and interactions.

The C4 software architecture model is a simple hierarchical way to think about the static structures of a software system in terms of containers, components and classes (or code). A software system is made up of one or more containers (web applications, mobile apps, standalone applications, databases, file systems, etc), each of which contains one or more components, which in turn are implemented by one or more classes. Visualising this hierarchy is then done by creating a collection of System Context, Container, Component and (optionally) Class diagrams. Structurizr is an implementation of the System Context, Container and Component diagrams.

System Context Diagram

A System Context diagram can be a useful starting point for diagramming and documenting a software system, allowing you to step back and look at the big picture. Draw a simple block diagram showing your system as a box in the centre, surrounded by its users and the other systems that it interfaces with. Detail isn't important here as this is your zoomed out view showing a big picture of the system landscape. The focus should be on people (actors, roles, personas, etc) and software systems rather than technologies, protocols and other low-level details. It's the sort of diagram that you could show to non-technical people.

Container Diagram

Once you understand how your system fits in to the overall IT environment with a System Context diagram, a really useful next step can be to illustrate the high-level technology choices with a Container diagram. A "container" is something like a web server, application server, desktop application, mobile app, database, file system, etc. Essentially, a container is anything that can execute code or host data. The Container diagram shows the high-level shape of the software architecture and how responsibilities are distributed across it. It also shows the major technology choices and how the containers communicate with one another. It's a simple, high-level technology focussed diagram that is useful for software developers and support/operations staff alike.

Component Diagram

Following on from a Container diagram showing the high-level technology decisions, you can then start to zoom in and decompose each container further. However you decompose your system is up to you, but this is about identifying the major logical structural building blocks and their interactions. The Component diagram shows how a container is divided into components, what each of those components are, their responsibilities and the technology/implementation details.