Software Architecture Design: Principles, Patterns, and Practical Approaches

The article explores the concept of software architecture, its definition, and its relationship with business. It begins by questioning what architecture is and how it adds value to a system, emphasizing that a good architecture should start from clear business scenarios and provide essential capabilities while ensuring safety, performance, and maintainability.

It defines architecture in both a general sense (a subjective mapping of elements and relationships) and a computing context (an abstract description of a software system’s overall structure and components). The discussion then moves to the role of architecture in engineering, using a building analogy to illustrate how architectural decisions affect the foundation, structure, and usability of a system.

The article outlines several core design principles, collectively known as the SOLID principles, and adds other important guidelines such as Ockham’s Razor, DRY, YAGNI, KISS, and POLA. Each principle is described with its intent and practical implications for software design.

Key principles highlighted include:

SRP (Single Responsibility Principle) : each function or module should have only one reason to change.

OCP (Open/Closed Principle) : modules should be open for extension but closed for modification.

LSP (Liskov Substitution Principle) : objects of a superclass should be replaceable with objects of a subclass without altering desirable properties.

ISP (Interface Segregation Principle) : clients should not be forced to depend on interfaces they do not use.

DIP (Dependency Inversion Principle) : high‑level modules should depend on abstractions, not concrete implementations.

Illustrative code examples demonstrate violations of LSP:

1. class Rectangle {
2. public:
3.     int32_t getWidth() const {return width;}
4.     int32_t getHeight() const {return height;}
5.
6.     virtual void setWidth(int32_t w) { width = w; }
7.     virtual void setHeight(int32_t h) { height = h; }
8.
9. private:
10.    int32_t width = 0;
11.    int32_t height = 0;
12. };

and

1. class Square : public Rectangle {
2. public:
3.     void setWidth(int32_t w) override { Rectangle::setWidth(w); Rectangle::setHeight(w); }
4.     void setHeight(int32_t h) override { /* … */ }
5. };
6. void reSize(Rectangle rect) {
7.     while (rect.getHeight() <= rect.getWidth()) {
8.         rect.setHeight(rect.getWidth() + 1);
9.     }
10. }

Another LSP violation example with birds and ostriches is also provided.

The article then surveys common architectural styles:

Layered Architecture : organizes code into layers with upper layers depending on lower ones.

Hexagonal (Ports‑and‑Adapters) Architecture : separates core business logic from external concerns via interfaces and dependency injection.

Onion (Clean) Architecture : builds on hexagonal ideas, adding domain‑driven design layers.

Domain‑Driven Design (DDD) : focuses on modeling the core business domain and its bounded contexts.

Practical experience with a large C++ codebase is described, highlighting challenges of deep dependency graphs and version conflicts. The solution involved introducing abstract interface layers and applying the Dependency Inversion Principle to decouple modules, resulting in a loosely‑coupled, “clean‑architecture‑like” layered system.

In conclusion, the author reflects that while many design principles exist, they are not absolute laws; the real value lies in using them to create simple, well‑structured, and business‑aligned software architectures.