Add Software Design

[QDenka]

https://github.com/QDenka/awesome-software-design#readme

Organizing and structuring software through patterns, decisions, and verified design rules.

By submitting this pull request I confirm I've read and complied with the below requirements 🖖

Requirements for your pull request

• Don't open a Draft / WIP pull request while you work on the guidelines. A pull request should be 100% ready and should adhere to all the guidelines when you open it.
• Don't waste my time. Do a good job, adhere to all the guidelines, and be responsive.
• You have to review at least 2 other open pull requests. Try to prioritize unreviewed PRs, but you can also add more comments to reviewed PRs.

PRs reviewed:

• Add AI Evaluation #3923

• Add Julia Security #3912

• You have read and understood the instructions for creating a list.

• This pull request has a title in the format Add Name of List.

• Your entry here should include a short description of the project/theme of the list.

• Your entry should be added at the bottom of the appropriate category.

• The title of your entry should be title-cased and the URL to your list should end in #readme.

• No blockchain-related lists.

• The suggested Awesome list complies with the below requirements.

Requirements for your Awesome list

• Has been around for at least 30 days. (First commit: January 5, 2026)
• Run awesome-lint on your list and fix the reported issues. ✔ Linting passes.
• The default branch should be named main.
• Includes a succinct description of the project/theme at the top of the readme.
• It's the result of hard work and the best I could possibly produce.
• The repo name is in lowercase slug format: awesome-software-design.
• The heading title is in title case format: Awesome Software Design.
• Non-generated Markdown file in a GitHub repo.
• The repo has awesome-list & awesome as GitHub topics, plus relevant topics.
• Not a duplicate. Differs from awesome-software-architecture (simskij) by focusing on code-level design: patterns with implementations, architecture decision records, design verification tools, and real-world case studies — rather than high-level architectural processes and frameworks.
• Only has awesome items. Curated, not collected.
• Does not contain unmaintained, archived, or deprecated items.
• Includes a project logo/illustration, centered.
• Entries have descriptions. Descriptions start with uppercase and end with a period.
• Includes the Awesome badge, linking back to this list.
• Has a Table of Contents section named Contents. No Contributing or Footnotes in ToC.
• Has CC0 license.
• Do not add the license name, text, or a License section to the readme.
• Has contribution guidelines (CONTRIBUTING.md).
• Has consistent formatting and proper spelling/grammar.
• Does not use hard-wrapping.
• Does not include a CI badge.
• Does not include an "Inspired by" link.

[QDenka]

unicorn

[jeyrb]

Good focused list (though with potential to bloat with tools which greatly outnumber the set of design things out there ). Already has awesome lint running with GHA.

[be-next]

Repo age concern. The GitHub API reports the repository was created on February 11, 2026 (createdAt: 2026-02-11T09:49:14Z), and this PR was opened on February 12 — one day later. The PR claims the first commit dates from January 5, but the 30-day requirement states: "30 days from either the first real commit or when it was open-sourced. Whatever is most recent." Since the repo was open-sourced on Feb 11, the 30-day eligibility window starts from that date — meaning the earliest this PR could qualify is around March 13, 2026.

Entry placement. The diff shows the entry inserted alphabetically next to "Software Architecture" rather than at the bottom of the Miscellaneous category, as required by the PR checklist ("Your entry should be added at the bottom of the appropriate category").

Overlap with existing awesome-software-architecture. The differentiation claim (code-level design vs. high-level architecture) is weakened by the actual content: the System Design section covers scalability, caching, and cloud patterns (AWS Well-Architected, Azure Architecture Center); the Real-World Architecture Examples section features Netflix, Uber, and Spotify case studies; and the ADR section is explicitly about architecture decision records. These are clearly architecture-level topics, overlapping significantly with the already-listed simskij/awesome-software-architecture.

Questionable items.

• fdaines/arch-go has only 2 GitHub stars — hard to justify as "awesome."
• keyvanakbary/learning-notes is described as "community notes on DDIA" but is actually one person's personal reading notes (last updated Jan 2024).
• Several repos have not seen activity in 1.5–2 years: tmrts/go-patterns (May 2024), npryce/adr-tools (Apr 2024), kgrzybek/modular-monolith-with-ddd (Jun 2024). The guidelines state "Does not contain items that are unmaintained."

Minor: The description of ArchUnitNET starts with .NET — the first character is a period, not an uppercase letter. Consider rewording to "C# port of ArchUnit for enforcing architecture rules in .NET projects."

[QDenka]

Repo age concern. The GitHub API reports the repository was created on February 11, 2026 (createdAt: 2026-02-11T09:49:14Z), and this PR was opened on February 12 — one day later. The PR claims the first commit dates from January 5, but the 30-day requirement states: "30 days from either the first real commit or when it was open-sourced. Whatever is most recent." Since the repo was open-sourced on Feb 11, the 30-day eligibility window starts from that date — meaning the earliest this PR could qualify is around March 13, 2026.

Entry placement. The diff shows the entry inserted alphabetically next to "Software Architecture" rather than at the bottom of the Miscellaneous category, as required by the PR checklist ("Your entry should be added at the bottom of the appropriate category").

Overlap with existing awesome-software-architecture. The differentiation claim (code-level design vs. high-level architecture) is weakened by the actual content: the System Design section covers scalability, caching, and cloud patterns (AWS Well-Architected, Azure Architecture Center); the Real-World Architecture Examples section features Netflix, Uber, and Spotify case studies; and the ADR section is explicitly about architecture decision records. These are clearly architecture-level topics, overlapping significantly with the already-listed simskij/awesome-software-architecture.

Questionable items.

• fdaines/arch-go has only 2 GitHub stars — hard to justify as "awesome."
• keyvanakbary/learning-notes is described as "community notes on DDIA" but is actually one person's personal reading notes (last updated Jan 2024).
• Several repos have not seen activity in 1.5–2 years: tmrts/go-patterns (May 2024), npryce/adr-tools (Apr 2024), kgrzybek/modular-monolith-with-ddd (Jun 2024). The guidelines state "Does not contain items that are unmaintained."

Minor: The description of ArchUnitNET starts with .NET — the first character is a period, not an uppercase letter. Consider rewording to "C# port of ArchUnit for enforcing architecture rules in .NET projects."

Thanks for the AI review

I went through each point and made concrete updates:

1. Repo age / 30-day rule - Agreed
2. Entry placement rule - Agreed.
3. I understand the concern, but this repo is intentionally focused on a different layer.
   awesome-software-architecture is primarily architecture-centric at a broad/system level.

My repository is design-in-practice oriented and focuses on:
• implementation-level design decisions,
• design verification in CI (architecture tests / fitness checks),
• ADR/RFC usage as an everyday engineering workflow,
• practical, code-adjacent resources for delivery teams.

4. Questionable items
   Fair, i already:
   • removed keyvanakbary/learning-notes
   • updated arch-go to the current repo: arch-go/arch-go
   • added explicit quality gates in CONTRIBUTING.md:

5. Minor style note (ArchUnitNET description)
   Fixed. Updated wording to:
   “C# port of ArchUnit for enforcing architecture rules in .NET projects.”

[aurumz-rgb]

I see you’ve addressed the formatting and the specific repo issues from the previous review, which is great.

However, I have two concerns regarding scope and positioning:

• Scope Overlap:
  You mentioned that this list focuses on “code-level design” to differentiate it from awesome-software-architecture. However, sections like System Design & API Foundations (e.g., system-design-primer, ByteByteGo) and Operational Case Studies (Netflix/Uber) lean more toward high-level architecture. These areas are already well covered in existing lists.

• Suggestion:
  To make this list more distinct (and avoid potential rejection as a duplicate), it would be better to narrow the focus to the more unique aspects such as Design Patterns, ADRs, and Architecture Verification (e.g., CI/Fitness Functions) and consider removing or trimming the high-level system design content.

Additionally, since the repository now satisfies the 30-day rule, that is no longer a concern.

Also, just to clarify: lack of recent commit activity or GitHub stars for an Awesome list isn’t necessarily an indicator of poor maintenance especially if the resources themselves are still valid and functional.

[sindresorhus]

• Significant overlap with existing awesome-software-architecture. The differentiation claim (code-level design vs. high-level architecture) doesn't hold up against the actual content. The list includes System Design resources (scalability, caching, load balancing via donnemartin/system-design-primer), cloud architecture patterns (AWS Well-Architected, Azure Architecture Center), Architecture Decision Records, operational case studies from Netflix/Uber/Spotify/Figma, and books like "Clean Architecture" and "Fundamentals of Software Architecture." These are all clearly architecture-level topics covered by the already-listed simskij/awesome-software-architecture. Convince me otherwise.

• Unmaintained entries still present. These were flagged in February and acknowledged but not removed:

  • tmrts/go-patterns - last push May 2024 (nearly 2 years ago)
  • npryce/adr-tools - last push April 2024
  • kgrzybek/modular-monolith-with-ddd - last push June 2024

  The guidelines say: "Does not contain items that are unmaintained."

• "System Design & API Foundations" is misplaced. This sub-section sits under "Decision Records (ADR/RFC)" but contains system design resources (system-design-primer, ByteByteGo, Kafka documentation, RabbitMQ tutorials, rate limiting strategies). These have nothing to do with decision records. Either move this to its own top-level section or rename the parent section.

• Top description is borderline. > Design-in-practice: implementation patterns, decision records, verification rules, and real operational lessons. lists what the list contains (categories of resources) rather than describing the subject itself. Something like "The discipline of organizing and structuring software at the code and component level." would describe the subject.

• Horizontal rules. The --- separators between sections are non-standard for awesome lists.

[omkar-foss]

PR looks great overall, few things to improve:

1. Consider removing horizontal rules (---), those are considered non-standard for awesome lists (refer this comment). Update: Looks like it's mentioned in above comment as well.
2. Items can be alphabetically arranged for easy reference.
3. Some items are directly under H2 while some are under H3 within the H2. (e.g. items directly under Implementation Patterns & Reference Code and then some under Design Patterns inside it). This can be simplified or more consistent.
4. Item naming can be simplified (e.g. ThreeDotsLabs/watermill can simply be Watermill).

[stuffbucket]

The heading is written as HTML (<h1 align="center">Awesome Software Design</h1>) rather than Markdown (# Awesome Software Design). The guidelines and awesome-lint both expect a standard Markdown heading. The centered styling looks nice, but it'll likely fail the lint check.

The focus on ADRs and fitness functions is a nice angle — that's more specific than most software design lists.

[QDenka]

• Significant overlap with existing awesome-software-architecture. The differentiation claim (code-level design vs. high-level architecture) doesn't hold up against the actual content. The list includes System Design resources (scalability, caching, load balancing via donnemartin/system-design-primer), cloud architecture patterns (AWS Well-Architected, Azure Architecture Center), Architecture Decision Records, operational case studies from Netflix/Uber/Spotify/Figma, and books like "Clean Architecture" and "Fundamentals of Software Architecture." These are all clearly architecture-level topics covered by the already-listed simskij/awesome-software-architecture. Convince me otherwise.

• Unmaintained entries still present. These were flagged in February and acknowledged but not removed:

  • tmrts/go-patterns - last push May 2024 (nearly 2 years ago)
  • npryce/adr-tools - last push April 2024
  • kgrzybek/modular-monolith-with-ddd - last push June 2024

  The guidelines say: "Does not contain items that are unmaintained."

• "System Design & API Foundations" is misplaced. This sub-section sits under "Decision Records (ADR/RFC)" but contains system design resources (system-design-primer, ByteByteGo, Kafka documentation, RabbitMQ tutorials, rate limiting strategies). These have nothing to do with decision records. Either move this to its own top-level section or rename the parent section.

• Top description is borderline. > Design-in-practice: implementation patterns, decision records, verification rules, and real operational lessons. lists what the list contains (categories of resources) rather than describing the subject itself. Something like "The discipline of organizing and structuring software at the code and component level." would describe the subject.

• Horizontal rules. The --- separators between sections are non-standard for awesome lists.

@sindresorhus

Thank you for the detailed review. Addressing each point:

---

1. Overlap with awesome-software-architecture

I audited both lists resource-by-resource. Out of ~90 entries, only 3 direct overlaps existed (Clean Architecture book, Structurizr, C4 Model). That said, you are right that the topical overlap was real - system design, cloud patterns, and infrastructure resources don't belong here.

All removed:

• donnemartin/system-design-primer, karanpratapsingh/system-design, ByteByteGo
• AWS Well-Architected, Azure Architecture Center, Serverless Land, Cell-Based Architecture
• Apache Kafka Documentation, RabbitMQ Tutorials, Rate Limiting Strategies
• High Scalability blog, Netflix OSS case studies, Uber microservices posts
• Fundamentals of Software Architecture (book)

What remains has zero overlap with simskij. Here is the differentiation:

Category	simskij/awesome-software-architecture	This list
Architecture Verification (CI/CD tests)	❌	✅ ArchUnit family (Java/C#/TS), arkitect, konsist, arch-go, go-cleanarch, Tach, Packwerk
ADR/RFC tooling + real RFC examples	concept only	✅ 8 tools + Kubernetes KEPs, Rust/Next.js/Flutter RFCs
Documentation-as-code tooling	Structurizr only	✅ D2, Mermaid, dependency-cruiser, PlantUML, Diagrams, Ilograph
Operational case studies (code-focused)	❌	✅ Figma CRDTs, Slack Flannel, Discord ScyllaDB, Linear sync, Notion sharding
Fitness functions	❌	✅
Cloud/system architecture	✅	❌ (removed)

---

2. Unmaintained entries all removed

All new additions verified as actively maintained (commits in 2025–2026).

---

3. "System Design & API Foundations" misplaced its fixed

The subsection has been removed from under "Decision Records" entirely. The 3 resources that were actually relevant (Google API Design Guide, Microsoft REST API Guidelines, Use The Index Luke) were moved to a new top-level section "API & Interface Design." Everything else (system-design-primer, ByteByteGo, Kafka, RabbitMQ, etc.) was deleted per point 1 above.

---

4. Top description rewritten

Old: Design-in-practice: implementation patterns, decision records, verification rules, and real operational lessons.

New: The discipline of organizing and structuring software at the code and component level.

---

5. Horizontal rules removed

All --- separators between sections have been removed.