book

Software Architecture and Design

Name: Software Architecture and Design
ISBN: 9781807789893

by Rheinwerk Publishing, Inc, Kristian Köhler

April 2026

Intermediate

491 pages

18h 4m

English

Packt Publishing

Read now

Unlock full access

Notes on Usage
1 Introduction
1.1 Programming Paradigms1.1.1 Structured Programming1.1.2 Object-Oriented Programming1.1.3 Functional Programming1.1.4 Reactive Programming
1.2 What Are Design Patterns and How Did They Come About?
1.3 What Are Software Architecture and Software Design?
1.3.1 Tasks of a Software Architecture1.3.2 Architectural Styles and Architectural Patterns
1.4 The Evolution of Software Development and Architecture
1.4.1 Class-Responsibility-Collaboration Cards1.4.2 The “Gang of Four” Patterns and Their Structure1.4.3 Clean Code1.4.4 Component-Based Development1.4.5 Core J2EE Patterns1.4.6 Enterprise Integration Patterns1.4.7 Well-Architected Cloud
2 Principles of Good Software Design
2.1 Basic Concepts of Object-Oriented Programming2.1.1 Objects and Classes2.1.2 Encapsulation2.1.3 Abstraction2.1.4 Inheritance2.1.5 Polymorphism
2.2 Clean Code Principles
2.2.1 Identifier Names and Conventions in the Code2.2.2 Defining Functions and Methods2.2.3 Don’t Repeat Yourself2.2.4 Establishing Clear Boundaries Between Components2.2.5 The Broken Windows Theory and the Boy Scout Rule in Software
2.3 SOLID Principles
2.3.1 The Single Responsibility Principle2.3.2 The Open-Closed Principle2.3.3 The Liskov Substitution Principle2.3.4 The Interface Segregation Principle2.3.5 The Dependency Inversion Principle and the Inversion of Control
2.4 Information Hiding
2.5 Inversion of Control and Dependency Injection

2.6 Separation of Concerns and Aspect Orientation
2.7 Quality Assurance with Unit Tests
3 Source Code and Documenting the Software Development
3.1 Comments in the Source Code3.1.1 Documenting Interfaces Using Comments3.1.2 Creating Expressive Code3.1.3 Necessary and Meaningful Comments3.1.4 Comments Not Needed
3.2 Documenting the Software Architecture
3.2.1 Documenting Quality Features3.2.2 Rules for Good Software Architecture Documentation3.2.3 arc42 for the Complete Documentation
3.3 Representing Software in Unified Modeling Language
3.3.1 Use Case Diagram3.3.2 Class Diagram3.3.3 Sequence Diagram3.3.4 State Diagram3.3.5 Component Diagram
3.4 C4 Model for Representing Software Architecture
3.4.1 System Context (Level 1 or C1)3.4.2 Container (Level 2 or C2)3.4.3 Component (Level 3 or C3)3.4.4 Code (Level 4 or C4)
3.5 Doc-as-Code
3.5.1 AsciiDoc3.5.2 PlantUML3.5.3 Structurizr
4 Software Patterns
4.1 Factory Method4.1.1 Problem and Motivation4.1.2 Solution4.1.3 Sample Solution4.1.4 When To Use the Pattern4.1.5 Consequences4.1.6 Real-World Example in Open-Source Software
4.2 Builder
4.2.1 Problem and Motivation4.2.2 Solution4.2.3 Sample Solution4.2.4 When To Use the Pattern4.2.5 Consequence4.2.6 Real-World Example in Open-Source Software
4.3 Strategy
4.3.1 Problem and Motivation4.3.2 Solution4.3.3 Sample Solution4.3.4 When To Use the Pattern4.3.5 Consequences4.3.6 Real-World Example
4.4 Chain of Responsibility
4.4.1 Problem and Motivation4.4.2 Solution4.4.3 Sample Solution4.4.4 When To Use the Pattern4.4.5 Consequences4.4.6 Real-World Example
4.5 Command
4.5.1 Problem and Motivation4.5.2 Solution4.5.3 Sample Solution4.5.4 When To Use the Pattern4.5.5 Consequences4.5.6 Real-World Example
4.6 Observer
4.6.1 Problem and Motivation4.6.2 Solution4.6.3 Sample Solution4.6.4 When To Use the Pattern4.6.5 Consequences4.6.6 Real-World Example
4.7 Singleton
4.7.1 Problem and Motivation4.7.2 Solution4.7.3 Sample Solution4.7.4 When To Use the Pattern4.7.5 Consequences4.7.6 Real-World Example
4.8 Adapter/Wrapper
4.8.1 Problem and Motivation4.8.2 Solution4.8.3 Sample Solution4.8.4 When To Use the Pattern4.8.5 Consequences4.8.6 Real-World Example
4.9 Iterator
4.9.1 Problem and Motivation4.9.2 Solution4.9.3 Sample Solution4.9.4 When To Use the Pattern4.9.5 Consequences4.9.6 Real-World Example
4.10 Composite
4.10.1 Problem and Motivation4.10.2 Solution4.10.3 Sample Solution4.10.4 When To Use the Pattern4.10.5 Consequences4.10.6 Real-World Example
4.11 The Concept of Anti-Patterns
4.11.1 Big Ball of Mud4.11.2 God Object4.11.3 Spaghetti Code4.11.4 Reinventing the Wheel4.11.5 Cargo Cult Programming
5 Software Architecture, Styles, and Patterns
5.1 The Role of the Software Architect
5.2 Software Architecture Styles
5.2.1 Client-Server Architecture5.2.2 Layered Architecture and Service Layers5.2.3 Event-Driven Architecture5.2.4 Microkernel Architecture or Plugin Architecture5.2.5 Microservices
5.3 Styles for Application Organization and Code Structure
5.3.1 Domain-Driven Design5.3.2 Strategic and Tactical Designs5.3.3 Hexagonal Architecture/Ports and Adapters5.3.4 Clean Architecture
5.4 Patterns for the Support of Architectural Styles
5.4.1 Model View Controller Pattern5.4.2 Model View ViewModel Pattern5.4.3 Data Transfer Objects5.4.4 Remote Facade Pattern
6 Communication Between Services
6.1 Styles of Application Communication6.1.1 Synchronous Communication6.1.2 Asynchronous Communication and Messaging6.1.3 Streaming
6.2 Resilience Patterns
6.2.1 Error Propagation6.2.2 Subdivision of the Resilience Patterns6.2.3 Timeout Pattern6.2.4 Retry Pattern6.2.5 Circuit Breaker Pattern6.2.6 Bulkhead Pattern6.2.7 Steady State Pattern
6.3 Messaging Patterns
6.3.1 Messaging Concepts6.3.2 Messaging Channel Patterns6.3.3 Message Construction Patterns6.3.4 Messaging Endpoint Pattern
6.4 Patterns for Interface Versioning
6.4.1 Endpoint for Version Pattern6.4.2 Referencing Message Pattern6.4.3 Self-Contained Message Pattern6.4.4 Message with Referencing Metadata6.4.5 Message with Self-Describing Metadata
7 Patterns and Concepts for Distributed Applications
7.1 Consistency
7.2 The CAP Theorem
7.3 The PACELC Theorem
7.4 Eventual Consistency
7.5 Stateless Architecture Pattern
7.5.1 Problem and Motivation7.5.2 Solution7.5.3 Sample Solution7.5.4 When To Use the Pattern7.5.5 Consequences
7.6 Database per Service Pattern
7.6.1 Problem and Motivation7.6.2 Solution7.6.3 Sample Solution7.6.4 When To Use the Pattern7.6.5 Consequences
7.7 Optimistic Locking Pattern
7.7.1 Problem and Motivation7.7.2 Solution7.7.3 Sample Solution7.7.4 When To Use the Pattern7.7.5 Consequences7.7.6 Pessimistic Locking
7.8 Saga Pattern: The Distributed Transactions Pattern
7.8.1 Problem and Motivation7.8.2 Solution7.8.3 Sample Solution7.8.4 When To Use the Pattern7.8.5 Consequences
7.9 Transactional Outbox Pattern
7.9.1 Problem and Motivation7.9.2 Solution7.9.3 Sample Solution7.9.4 When To Use the Pattern7.9.5 Consequences
7.10 Event Sourcing Pattern
7.10.1 Problem and Motivation7.10.2 Solution7.10.3 Sample Solution7.10.4 When To Use the Pattern7.10.5 Consequences
7.11 Command Query Responsibility Segregation Pattern
7.11.1 Problem and Motivation7.11.2 Solution7.11.3 Sample Solution7.11.4 When To Use the Pattern7.11.5 Consequences
7.12 Distributed Tracing Pattern
7.12.1 Problem and Motivation7.12.2 Solution7.12.3 Sample Solution7.12.4 When To Use the Pattern7.12.5 Consequences
The Author
Index
Service Pages
Legal Notes

Content preview from Software Architecture and Design

2.4 Information Hiding

The principle of information hiding is a cornerstone of good software design, and I have already described it indirectly in a few places without mentioning it explicitly. According to this principle, data and functions within a component are hidden from the outside as far as possible, and only the important or relevant information is visible outside the component.

“Less is more, but not less than necessary.” —Wisdom of information hiding

The key principles of information hiding are encapsulation and abstraction. Both are intended to minimize the dependencies of the components in order to create a more flexible, robust, and maintainable software design.

The lower the dependencies between the components, the better the ...

Become an O’Reilly member and get unlimited access to this title plus top books and audiobooks from O’Reilly and nearly 200 top publishers, thousands of courses curated by job role, 150+ live events each month,
and much more.

Read now

Unlock full access

More than 5,000 organizations count on O’Reilly

O’Reilly covers everything we've got, with content to help us build a world-class technology community, upgrade the capabilities and competencies of our teams, and improve overall team performance as well as their engagement.

Julian F.

Head of Cybersecurity

I wanted to learn C and C++, but it didn't click for me until I picked up an O'Reilly book. When I went on the O’Reilly platform, I was astonished to find all the books there, plus live events and sandboxes so you could play around with the technology.

Addison B.

Field Engineer

I’ve been on the O’Reilly platform for more than eight years. I use a couple of learning platforms, but I'm on O'Reilly more than anybody else. When you're there, you start learning. I'm never disappointed.

Amir M.

Data Platform Tech Lead

I'm always learning. So when I got on to O'Reilly, I was like a kid in a candy store. There are playlists. There are answers. There's on-demand training. It's worth its weight in gold, in terms of what it allows me to do.

Mark W.

Embedded Software Engineer

Publisher Resources

ISBN: 9781807789893

Cloud Computing

Data Engineering

Data Science

AI & ML

Programming Languages