Software Architecture Design: Principles, Complexity, and Best Practices

Software architecture is a classic topic in computer science. In production environments we often face architectural shortcomings, aging interfaces, and code rot. Under fast‑changing business demands, a good architecture must be the result of deep thinking and be highly extensible.

Using the concept of entropy from physics, the article draws an analogy: just as entropy in a thermodynamic system tends to increase, software systems also accumulate disorder (technical debt) when they are not actively refactored.

The "broken‑window" effect is introduced – if minor defects or bad practices are left unattended, they encourage more violations, eventually making the system hard to maintain.

Two dimensions of software value are discussed:

Behavior value : the system’s functionality – writing code that satisfies requirements and fixing bugs.

Architecture value : the system’s structure – flexibility, low cost, and ease of modification.

The article emphasizes that architecture should support the entire lifecycle of a system, maximizing developer productivity while minimizing operational cost.

Complexity is defined as the weighted sum of each part’s complexity multiplied by the time developers spend on it. Three symptoms of rising complexity are highlighted:

Change amplification – a simple change requires modifications in many places.

Cognitive load – developers need excessive knowledge to complete a task.

Unknown unknowns – it is unclear which code must be changed or what information is needed.

Complexity originates from two sources: dependencies and obscurity. Reducing unnecessary dependencies and making information explicit are key mitigation strategies.

Several well‑known design principles are presented:

Ockham’s razor – keep designs as simple as possible.

Consistency – similar things should be done in similar ways.

Orthogonality – independent components can change without affecting each other.

Reversibility – hide third‑party APIs behind abstraction layers.

DRY (Don’t Repeat Yourself) – eliminate duplication in code, data, APIs, documentation, tools, and services.

Design twice – consider multiple alternatives before committing to a design.

Layering and abstraction are described using the TCP/IP model as an example: each layer provides a distinct abstraction and only interacts with adjacent layers.

Complexity should be “pushed down” to the lowest possible layer (e.g., Go’s scheduler, Service Mesh) so that higher‑level code remains simple.

Component coupling principles are outlined:

No cyclic dependencies.

Stable‑dependency principle – depend on more stable components.

Stable‑abstraction principle – the level of abstraction should match stability.

Boundary definition (Domain‑Driven Design’s bounded contexts) helps isolate core business logic from peripheral concerns.

Communication and integration patterns such as anti‑corruption layers, open host services, and publish/subscribe events are discussed as ways to reduce coupling.

The article stresses that databases, web UI, and frameworks are “details” that should be kept at arm’s length from core business logic.

Finally, the importance of UML (use‑case diagrams, class diagrams, activity diagrams, sequence diagrams, state diagrams) for visualizing architecture is highlighted, and a list of classic books for further reading is provided.

For readers who find the article helpful, sharing is encouraged.