software-patterns

name	software-patterns
description	Compare tradeoffs and recommend architectural patterns — dependency injection, service-oriented architecture, repository, domain events, circuit breaker, and anti-corruption layer. Use when choosing between design patterns, planning microservices boundaries, evaluating system design alternatives, or asking 'which pattern should I use' for a specific coupling or resilience problem.
user-invocable	false
disable-model-invocation	true
version	1.1.0
updated	2026-06-15
languages	all
progressive_disclosure	{"entry_point":{"summary":"Compare tradeoffs and recommend architectural patterns for coupling, resilience, and boundary problems","when_to_use":"When choosing between design patterns, planning microservices, evaluating dependency injection vs service locator, or deciding how to decouple services","quick_start":"1. Identify the problem class 2. Check decision tree 3. Apply foundational patterns (DI+SOA) 4. Layer situational patterns as needed"},"references":["foundational-patterns.md","situational-patterns.md","anti-patterns.md","decision-trees.md","examples.md","code-smell-signals.md"]}
tags	["architecture","patterns","design-patterns","dependency-injection","service-oriented-architecture","microservices","system-design"]

Software Patterns Primer

Overview

Architectural patterns solve specific structural problems. This skill provides a decision framework for when to apply each pattern, not a catalog to memorize.

Core philosophy: Patterns solve problems. No problem? No pattern needed.

When to Use This Skill

Activate when:

• Designing a new system or major feature
• Adding external service integrations
• Code becomes difficult to test or modify
• Services start calling each other in circles
• Failures in one component cascade to others
• Business logic scatters across multiple locations

Pattern Hierarchy

Foundational (Apply by Default)

These patterns provide the structural foundation for maintainable systems. Apply unless you have specific reasons not to.

Pattern	Problem Solved	Signal to Apply
Dependency Injection	Tight coupling, untestable code	Classes instantiate their own dependencies
Service-Oriented Architecture	Monolithic tangles, unclear boundaries	Business logic scattered, no clear ownership

DI quick example — before and after:

# BEFORE: tight coupling, hard to test
class OrderService:
    def __init__(self):
        self.db = PostgresDatabase()       # concrete dependency
        self.mailer = SmtpMailer()         # concrete dependency

# AFTER: dependencies injected, easily testable
class OrderService:
    def __init__(self, db: Database, mailer: Mailer):
        self.db = db
        self.mailer = mailer
# In tests: OrderService(db=FakeDatabase(), mailer=FakeMailer())