Software Design and Architecture
Software design and architecture concern how a software system is structured into components and connectors, how responsibilities are decomposed, and how design decisions satisfy functional needs and quality attributes.
Definition
Software design is the process of defining the architecture, components, interfaces, and other characteristics of a system, and software architecture is the set of structures comprising the system's elements, their relations, and the properties of both.
Scope
This area covers architectural styles and patterns (layered, client-server, microservices, event-driven, pipe-and-filter); design principles such as modularity, information hiding, cohesion, coupling, and separation of concerns; object-oriented and component-based design; design patterns; architectural quality attributes and their trade-offs; and modeling notations such as UML used to express designs.
Sub-topics
Core questions
- How should a system be decomposed into modules and components?
- Which architectural style best supports the required quality attributes?
- How do design principles like coupling and cohesion guide good structure?
- How are recurring design problems solved by reusable patterns?
Key theories
- Information hiding and modularity
- Parnas argued that modules should be defined to hide design decisions likely to change behind stable interfaces, so that change is localized; this principle underlies modularity, encapsulation, and low coupling.
- Architectural quality attributes and trade-offs
- Architecture is driven by quality attributes such as performance, modifiability, availability, and security; because these conflict, architecture is fundamentally about reasoning over trade-offs guided by tactics and patterns.
- Design patterns
- Recurring design problems have well-understood, named solutions — creational, structural, and behavioral patterns — that capture expert practice and provide a shared vocabulary for object-oriented design.
Clinical relevance
Architecture decisions are the hardest to change later and most strongly determine a system's quality attributes, so sound design and architecture reduce long-term maintenance cost, enable scalability and evolution, and shape team organization.
Evidence & guidelines
ISO/IEC/IEEE 42010 standardizes architecture description, and the SWEBOK Software Design knowledge area together with reference texts such as Software Architecture in Practice provide consensus guidance.
History
Modular design principles were articulated by Parnas in the early 1970s. Object-oriented design and design patterns matured in the 1980s and 1990s, software architecture emerged as a distinct discipline with Shaw and Garlan's work in the mid-1990s, and service-oriented and microservice styles followed in the 2000s and 2010s.
Debates
- Monolithic versus microservice architecture
- Whether to build systems as a single deployable monolith or as many independently deployable services is widely debated; microservices offer independent scaling and deployment at the cost of distributed-system complexity, so the right choice depends on scale and organizational structure.
Key figures
- David Parnas
- Mary Shaw
- Len Bass
- Erich Gamma
- Grady Booch
Related topics
Seminal works
- parnas1972
- gamma1994
- bass2012
Frequently asked questions
- What is the difference between design and architecture?
- Architecture concerns the highest-level structures and the decisions that are most costly to change — major components, their interactions, and system-wide quality attributes — while design covers the more detailed internal structure of those components; the boundary is one of significance rather than a sharp line.
- Why do design patterns matter?
- Patterns capture proven solutions to recurring design problems and give engineers a shared vocabulary, making designs easier to communicate, reason about, and evolve; they are guidance to be applied judiciously, not mandatory recipes.