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 Awesome 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.”