# Recommended Resources for Software Architecture: A Curated Guide from Every Programmer Should Know

> Explore top software architecture resources in this curated guide. Discover essential materials on design patterns and system engineering from the mtdvio every-programmer-should-know repository.

- Repository: [MTDV/every-programmer-should-know](https://github.com/mtdvio/every-programmer-should-know)
- Tags: tutorial
- Published: 2026-02-26

---

**The `mtdvio/every-programmer-should-know` repository maintains a hand‑picked list of high‑quality material covering architectural thinking, design patterns, and system‑level engineering, including seminal papers like *Out of the Tar Pit* and *No Silver Bullet*.**

Software architecture forms the backbone of maintainable, scalable systems. The open‑source curation at `github.com/mtdvio/every-programmer-should-know` collects essential readings and videos that every developer should study to move from writing code to designing systems. These resources span from foundational theory to concrete implementation patterns like CQRS and Event Sourcing.

## Foundational Architecture Concepts

Building a solid architectural mindset starts with understanding the core principles of system design and complexity management.

### Visual System Thinking

**[A Field Guide to Boxology](https://github.com/mtdvio/every-programmer-should-know/blob/master/README.md#L123)** introduces visual "box‑and‑arrow" thinking for high‑level system diagrams. This resource teaches you to sketch the big picture before diving into implementation details, making it invaluable for whiteboard sessions and design reviews.

### Complexity and Abstraction

**[Out of the Tar Pit](https://github.com/mtdvio/every-programmer-should-know/blob/master/README.md#L124)** is a classic essay that argues for simple, orthogonal abstractions and warns against over‑engineered solutions. It provides a philosophical foundation for keeping systems maintainable by minimizing state and managing complexity.

**[No Silver Bullet – Essence and Accidents of Software Engineering](https://github.com/mtdvio/every-programmer-should-know/blob/master/README.md#L125)** presents Fred Brooks’ seminal paper on the inherent challenges of building large systems. Understanding the difference between essential complexity and accidental complexity is crucial for making realistic architectural decisions.

## Architectural Patterns and Practices

Moving from theory to practice requires knowledge of specific patterns that solve recurring design problems.

### Domain-Driven Design and Event Patterns

**[CQRS and Event Sourcing (video)](https://github.com/mtdvio/every-programmer-should-know/blob/master/README.md#L127)** explains command‑query separation and immutable event streams. These patterns form the core of scalable, maintainable systems where write and read models are optimized independently.

**[Practical Object‑Oriented Design in Ruby (POODR)](https://github.com/mtdvio/every-programmer-should-know/blob/master/README.md#L128)** teaches SOLID principles, encapsulation, and testability. Though Ruby‑centric, these object‑oriented design principles apply to any OO language and provide a foundation for clean architecture.

### Evolutionary and System Design

**[Growing a Language (video)](https://github.com/mtdvio/every-programmer-should-know/blob/master/README.md#L126)** demonstrates how languages and runtimes evolve, reinforcing that architecture must remain adaptable to changing requirements and technologies.

**[Evolutionary Software Architectures (video)](https://github.com/mtdvio/every-programmer-should-know/blob/master/README.md#L129)** discusses designing systems that can be refactored safely as requirements change. This approach emphasizes automated testing and incremental change over big‑bang rewrites.

**[System Design: A Primer (GitHub repo)](https://github.com/mtdvio/every-programmer-should-know/blob/master/README.md#L130)** provides a curated collection of interview‑style system‑design questions, diagrams, and walkthroughs. This practical resource bridges the gap between theory and real‑world scalability challenges.

## Specialized Architecture Topics

For specific domains and runtime environments, the repository includes targeted resources.

**[How JavaScript works (Medium series)](https://github.com/mtdvio/every-programmer-should-know)** offers a deep dive into the event loop, memory management, and optimization. This knowledge is essential when architecting front‑end applications or Node.js services.

**[ECS Architecture with Unity (video)](https://github.com/mtdvio/every-programmer-should-know/blob/master/README.md#L132)** provides a concrete example of Entity‑Component‑System architecture, a data‑driven pattern used in game development and high‑performance applications.

## Practical Implementation Examples

Understanding architectural theory becomes easier with concrete code demonstrations.

### Event Sourcing in Node.js

The following snippet illustrates a minimal event‑store implementation based on the patterns recommended in the repository:

```javascript
// A minimal event‑store implementation
class EventStore {
  constructor() { this.events = [] }
  append(event) { this.events.push(event) }
  replay(aggregate) {
    this.events.forEach(e => aggregate.apply(e))
  }
}

// Example aggregate
class BankAccount {
  constructor() { this.balance = 0 }
  apply(event) {
    if (event.type === 'Deposited') this.balance += event.amount
  }
}

// Usage
const store = new EventStore()
store.append({type: 'Deposited', amount: 50})
store.append({type: 'Deposited', amount: 20})

const account = new BankAccount()
store.replay(account)
console.log(account.balance) // → 70

```

This example demonstrates the core concept behind **CQRS/Event Sourcing**—all state changes are immutable events that can be replayed to reconstruct the current state.

### Visual Architecture with Boxology

The repository recommends visual "box‑and‑arrow" thinking for system design. Here is a PlantUML example demonstrating this approach:

```plantuml
@startuml
node "Client" as C
node "API Gateway" as GW
component "Auth Service" as Auth
component "Order Service" as Order
database "PostgreSQL" as DB

C --> GW : HTTP
GW --> Auth : JWT verify
GW --> Order : REST
Order --> DB : SQL
@enduml

```

This diagram illustrates the **Boxology** approach—each box (node/component) has a single responsibility, and arrows show explicit communication paths. Keeping such diagrams alongside your codebase ensures architecture remains visible and maintainable.

## Key Repository Files

The architectural recommendations in this guide are maintained in the following files within the `mtdvio/every-programmer-should-know` repository:

- **[[`README.md`](https://github.com/mtdvio/every-programmer-should-know/blob/main/README.md)](https://github.com/mtdvio/every-programmer-should-know/blob/master/README.md)** – The central catalog containing all recommended resources, including the Architecture section referenced throughout this guide (lines 123–132).
- **[[`CONTRIBUTING.md`](https://github.com/mtdvio/every-programmer-should-know/blob/main/CONTRIBUTING.md)](https://github.com/mtdvio/every-programmer-should-know/blob/master/CONTRIBUTING.md)** – Guidelines for submitting new architectural resources or updates to the existing curation.
- **[`LICENSE`](https://github.com/mtdvio/every-programmer-should-know/blob/master/LICENSE)** – Defines the open‑source terms under which this curated knowledge base is shared.

## Summary

- The **`mtdvio/every-programmer-should-know`** repository curates essential **recommended resources for software architecture**, ranging from theoretical papers to practical implementation guides.
- Foundational readings like *Out of the Tar Pit* and *No Silver Bullet* provide the philosophical groundwork for managing complexity and avoiding over‑engineering.
- Practical patterns including **CQRS**, **Event Sourcing**, and **Domain‑Driven Design** are covered through video tutorials and language‑agnostic books like *POODR*.
- The repository emphasizes **evolutionary architecture**—designing systems that can be safely refactored as requirements change, supported by resources like *System Design: A Primer*.
- Concrete implementation examples in JavaScript and PlantUML demonstrate how to apply these architectural concepts in real codebases.

## Frequently Asked Questions

### What is the best starting point for learning software architecture from this repository?

Begin with **[A Field Guide to Boxology](https://github.com/mtdvio/every-programmer-should-know/blob/master/README.md#L123)** to learn visual system thinking, then read **[Out of the Tar Pit](https://github.com/mtdvio/every-programmer-should-know/blob/master/README.md#L124)** to understand complexity management. These two resources provide the conceptual foundation needed before diving into specific patterns like CQRS or microservices.

### How does the Every Programmer Should Know repository organize its architecture recommendations?

The repository organizes resources in the **[[`README.md`](https://github.com/mtdvio/every-programmer-should-know/blob/main/README.md)](https://github.com/mtdvio/every-programmer-should-know/blob/master/README.md)** file, specifically around lines 123–132, grouping them by topic rather than difficulty level. Categories include fundamental theory (Boxology, No Silver Bullet), specific patterns (CQRS, Event Sourcing), language‑agnostic design (POODR), and practical system design interview preparation.

### What is the difference between CQRS and Event Sourcing as recommended in the repository?

**CQRS (Command Query Responsibility Segregation)** separates read and write operations into different models, optimizing each for their specific workload. **Event Sourcing** persists state changes as a sequence of immutable events rather than storing only the current state. While often used together—as demonstrated in the repository's recommended video at line 127—they are distinct patterns: CQRS addresses operational separation, while Event Sourcing addresses data persistence and audit trails.

### Why is "No Silver Bullet" considered essential reading for software architects?

Fred Brooks' paper **[No Silver Bullet – Essence and Accidents of Software Engineering](https://github.com/mtdvio/every-programmer-should-know/blob/master/README.md#L125)** distinguishes between **essential complexity** (inherent to the problem being solved) and **accidental complexity** (introduced by implementation details). Understanding this distinction prevents architects from chasing silver‑bullet technologies that promise to eliminate inherent difficulty, leading to more realistic project planning and technology selection.