ScholarGate
Assistant

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.

Methods for this concept

Related concepts