I Curated 106 Software Design Resources and Ranked What Actually Matters

Most developers learn design patterns from a textbook, forget them in a week, and never apply them.

I spent years doing the same. Then I decided to fix it — not just for myself, but for everyone stuck in that loop.

I went through hundreds of repositories, articles, books, and tools. I kept only what actually helped me write better code. The result: Awesome Software Design — 106 curated resources across 10 categories.

Here's what I learned in the process.

Software Design ≠ Software Architecture

This was my first big realization. Most people use these terms interchangeably. They shouldn't.

Architecture answers: What do we build? Monolith or microservices? Which cloud? How do services communicate?

Design answers: How do we write the code? Which pattern solves this problem? How do we structure modules? How do we verify our design rules hold?

There's already an awesome-software-architecture list. It covers the high-level stuff well. But when I looked for resources on the code level — patterns with real implementations, ADR templates teams actually use, tools that enforce design rules in CI — there was a gap.

The 5 Categories That Changed How I Code

1. Architecture Decision Records (ADR)

This was the biggest surprise. I'd never heard of ADRs until a year ago. Now I can't imagine working without them.

An ADR is a short document capturing why you made a technical decision. Not what, not how — why.

# ADR-001: Use Event Sourcing for Payment Module

## Status: Accepted

## Context
We need full audit trail for all payment state changes...

## Decision
We will use event sourcing for the payment bounded context...

## Consequences
- Complete audit history without additional logging
- Increased storage requirements
- Team needs training on event sourcing patterns

I found 14 real-world ADR examples — from Kubernetes KEPs to Spotify's ADR practice to Rust RFCs. Reading how top engineering teams document decisions taught me more than any course.

Start here: joelparkerhenderson/architecture-decision-record — templates + examples.

2. Design Verification (Enforce Rules, Don't Just Document Them)

This category barely existed in other lists. It's my favorite.

You can write all the architecture rules you want in Confluence. Nobody reads them. Instead, test your architecture:

// Using phparkitect/arkitect
$rules = Rule::allClasses()
    ->that(new ResideInOneOfTheseNamespaces('App\Domain'))
    ->should(new NotDependsOnTheseNamespaces('App\Infrastructure'))
    ->because('Domain layer must not depend on infrastructure');

// Using TNG/ArchUnit
@ArchTest
static final ArchRule domainMustNotAccessInfra =
    noClasses().that().resideInAPackage("..domain..")
        .should().dependOnClassesThat().resideInAPackage("..infrastructure..");

Your design rules run in CI. Every PR. No exceptions. No "we'll fix it later."

Tools by language:

• PHP → phparkitect/arkitect
• PHP/Laravel → pestphp/pest-plugin-arch
• Java → TNG/ArchUnit
• Go → fdaines/arch-go
• Kotlin → LemonAppDev/konsist

3. Real-World Architecture Case Studies

Textbooks show you patterns in isolation. Reality is messier. I collected case studies from companies that actually built these systems:

• Shopify stayed on a monolith — but deconstructed it into modules. Proof that you don't need microservices.
• Discord migrated from Cassandra to ScyllaDB to handle trillions of messages. The engineering post reads like a thriller.
• Figma built real-time collaboration with CRDTs. Understanding their trade-offs changed how I think about consistency.
• Stripe wrote the definitive guide on API design — backward compatibility at scale.

Reading these is worth more than 10 tutorials.

4. Reference Implementations

The gap between "I understand the pattern" and "I can implement it" is huge. Reference implementations bridge it.

The best ones I found:

• ThreeDotsLabs/wild-workouts-go-ddd-example — Clean Architecture + CQRS in Go, with a blog series explaining every decision.
• kgrzybek/modular-monolith-with-ddd — The most complete Modular Monolith example I've seen. C#, but the patterns are universal.
• CodelyTV/php-ddd-example — DDD + Hexagonal in PHP/Symfony. If you're a PHP developer, start here.

5. The Books That Actually Matter

I've seen lists with 50+ books. Nobody reads 50 architecture books. Here are the ones that changed my thinking:

For understanding complexity: A Philosophy of Software Design by Ousterhout. Short, opinionated, practical.

For domain modeling: Learning Domain-Driven Design by Khononov. Skip the Blue Book if you're starting out — this is more accessible and modern.

For distributed systems: Designing Data-Intensive Applications by Kleppmann. Non-negotiable if you work with data at any scale.

What I Filtered Out

Curating means saying no. I removed:

• Unmaintained repos — last commit 3+ years ago
• Tutorial collections — "100 design pattern tutorials" with no quality filter
• Duplicates — if Refactoring.Guru covers it better, one link is enough
• Hype without substance — "microservices solve everything" content
• Generic advice — "use SOLID principles" without showing how

The hardest part was cutting resources I personally liked but that didn't add unique value.

The Numbers

Final result:

• 106 resources across 10 sections
• 14 ADR examples from real companies
• 7 design verification tools across 5 languages
• 10 real-world case studies from Spotify, Netflix, Uber, Discord, and others
• 11 books — only the ones that earn their page count

What This Taught Me

1. Design patterns are a language, not a checklist. The value isn't memorizing all 23 GoF patterns. It's being able to say "this is a Strategy problem" and having your team instantly understand.

2. ADRs are the most underrated practice in software engineering. Every team should document decisions. Future-you will thank present-you.

3. Architecture tests > architecture documents. If a rule isn't enforced, it doesn't exist.

4. Read case studies, not just theory. Understanding why Discord moved off Cassandra teaches more about database selection than any comparison chart.

5. Curating is harder than collecting. Anyone can aggregate 500 links. The value is in the 106 that matter.

The full list is here: Awesome Software Design

If it's useful, a ⭐ helps others find it. If I missed something great, contributions are welcome.

What design resources changed how you write code? I'd love to hear what I should add.