Vol 6: Software Engineering and Design Patterns
This volume asks whether software remains understandable, testable, and deliverable after several rounds of change. Requirements, contracts, tests, and architecture belong in the same discussion. Design patterns enter when there is a specific change to handle; every class does not need a grand job title.
Prerequisites
- Be able to write a small program with several functions or classes and save changes with Git. Volume 1 and Volume 0 cover those foundations.
- The service, messaging, and consistency lessons assume basic HTTP and transaction knowledge. Consult Volume 4 and Volume 5 as needed.
Coverage
Chapters 1–6 connect requirements, code, and delivery through feedback. Chapters 7–10 cover design principles and patterns; Chapters 11–17 cover architecture, services, messaging, and deployment. The final three examine AI systems, API contracts, and domain modeling.
Chapter 1
Chapter 2
- 2.1 ADT Specifications, Representation, and Invariants
- 2.2 Immutability, Representation Leaks, and Equality
Chapter 3
- 3.1 From Problem Statement to Verifiable Requirements
- 3.2 Architecture Views, Quality Trade-offs, and Decision Records
Chapter 4
- 4.1 Risk-Driven Test Combinations and Unit Testing
- 4.2 Integration, Contracts, End-to-End, and Continuous Feedback
Chapter 5
- 5.1 Verifiable Refactoring in Small Steps
- 5.2 Code Quality Signals, Static Analysis, and Code Reviews
Chapter 6
- 6.1 Continuous Integration, Reproducible Builds, and Pipeline Security
- 6.2 Artifact Promotion, Deployment Strategies, and Recoverable Delivery
Chapter 7
- 7.1 Understanding SRP, OCP, and DIP Through Change
- 7.2 Substitutability, Interface Segregation, and Composition
Chapter 8
Chapter 9
- 9.1 Boundary Adaptation: Adapter, Facade, Proxy, and Bridge
- 9.2 Composable Structures: Decorator, Composite, and Flyweight
Chapter 10
- 10.1 Replaceable Strategies, Flow Skeletons, Responsibility Chains, and Commands
- 10.2 Event Notification, State Behavior, and Centralized Coordination
- 10.3 Traversals, Snapshots, External Operations, and Small Languages
Chapter 11
- 11.1 Layering Goes Beyond Folder Separation: Responsibilities, Dependencies, and Transaction Boundaries
- 11.2 MVC, MVP, and MVVM: Who Owns the Interaction State
Chapter 12
- 12.1 Hexagonal Architecture: Protecting the Business Core with Ports
- 12.2 Dependency Rules: How Clean Architecture Translates to Code
Chapter 13
- 13.1 Modular Monoliths: First Establish Boundaries, Then Add Deployment Units
- 13.2 Risk-Driven Service Extraction and Strangler Migration
Chapter 14
- 14.1 Service Discovery, Gateway, BFF, and Configuration Boundaries
- 14.2 Deadline, Retries, Circuit Breakers, and Overload Protection
Chapter 15
- 15.1 Consistency Boundaries and Saga: Transforming Long Transactions into Recoverable Flows
- 15.2 Outbox, Idempotent Consumption, and Recoverable Messages
- 15.3 CQRS and Event Sourcing: Separate Models and Store Facts
Chapter 16
- 16.1 Deployment and Release: Rolling, Blue-Green, Canary, and Feature Flags
- 16.2 Sidecar, Ambassador, Adapter, and Fault Injection Experiments
Chapter 17
- 17.1 Event Contracts, Delivery Semantics, and Consumer Idempotency
- 17.2 Publish/Subscribe, Stream Processing, and Event Pipeline Observability
Chapter 18
- 18.1 RAG: From Retrieval of Knowledge to Verifiable Answers
- 18.2 Workflows and Agents: Tools, Loops, and Permission Boundaries
- 18.3 Evaluation, Caching, and Production Operations
Chapter 19
- 19.1 HTTP API: Resources, Semantics, Concurrency, and Recoverable Requests
- 19.2 OpenAPI, gRPC, AsyncAPI, and Contract Evolution
Chapter 20
- 20.1 Strategic DDD: Subdomains, Bounded Contexts, and a Shared Language
- 20.2 Tactical Modeling: Entities, Value Objects, Aggregates, and Repositories
- 20.3 Context Integration: Domain Events, ACLs, and Model Evolution
Outcomes
- Turn vague requirements into checkable behavior and choose tests that expose consequential errors.
- Choose abstractions, patterns, and module boundaries based on how code needs to change, then verify small refactoring steps.
- Analyze failures during service extraction, message delivery, and deployment, and design ways to recover and verify the result.
How to use this map
Bring a small project of your own to Chapters 1–6 and revise it as you read. Before looking up a pattern, describe what currently makes the code hard to change, then see whether Chapters 7–10 help. For service extraction, API changes, or duplicate messages, jump to the later chapters. Aim to explain the cost of your choice as well as the pattern name.