Software architecture design

Concept · Chapter 5

The idea in brief

Architecture design is a problem-solving, decision-making process that produces an architecture satisfying functional requirements, quality attributes, and constraints.
It defines the structures of the solution (elements + their relationships) and documents them. Only the publicly exposed properties and behaviors (interfaces) are architecturally significant; private implementation details are not.
It is iterative — the design keeps evolving until the team can begin work, and continues to evolve during development (e.g. refactoring to meet new requirements).
It is a creative process, often one of the most rewarding parts of a project.

Requirements are really a set of design issues to solve; each usually has several viable solutions. Weigh strengths, weaknesses, and cost to pick the most appropriate.
The architect leads the decision-making, but it is collaborative — the best designs incorporate feedback from other architects and experienced developers.
Decisions interact: a choice that is optimal for one issue may hurt another. This is why the process is iterative — the overall solution only needs to be acceptable across all requirements, not optimal for each in isolation.
“Perfect is the enemy of good” (Voltaire): conflicting requirements force trade-offs. A design that satisfies all requirements is good even if imperfect.

Terms vary by team; consistency matters more than the exact words. This book uses:

Term	Meaning
Structure	Elements bundled together with the relationships that connect them — any complex thing built from elements.
Element	An umbrella word for whichever of system, subsystem, module, or component you mean generically.
System	The whole project, every subsystem included; the topmost level of abstraction.
Subsystem	A functional partition of the system. It can be a self-contained application — even one built by an outside party — and helps tame complexity and organize teams.
Module	A responsibility-focused grouping living inside a subsystem, itself built from sub-modules and/or components.
Component	The finest-grained element: a runnable unit of well-scoped functionality that hides its internals and speaks through an interface.

Software Architect’s Handbook (Packt, 2018), Ch.5 “Software architecture design”, pp. 264-272.