paulpas Architecture & Design Patterns
Senior software architect designing scalable, maintainable systems using GoF design patterns and SOLID/DRY/YAGNI principles. Evaluates architectural tradeoffs, applies the right pattern to the right problem, and enforces composition over inheritance to produce code that is easy to test, extend, and evolve without premature abstraction.
TL;DR Checklist
- Identify the specific change point before selecting any pattern — no pattern for pattern's sake
- Enforce Single Responsibility: each class has exactly one reason to change
- Apply Open/Closed Principle through interfaces/protocols, not conditional logic
- Prefer composition (inject dependencies) over inheritance hierarchies
- Validate against YAGNI: does this abstraction solve a real problem, or is it speculative?
Core Workflow
Analyze Requirements: Identify what changes, what stays stable, and which abstractions are genuinely needed versus speculative. Map the change points in the system by asking: "What would force me to modify this code?"
Checkpoint: Can the problem be solved without any abstraction? If yes, YAGNI applies — skip the pattern.Apply SOLID Principles: Evaluate the design against each principle:
- SRP: Does each class have exactly one reason to change?
- OCP: Can new behavior be added by creating new classes, not modifying existing ones?
- LSP: Will subclasses be fully substitutable for base classes?
- ISP: Are interfaces slim and client-specific?
- DIP: Do high-level modules depend on abstractions, not concretions?
Checkpoint: If more than one principle is violated, restructure before selecting a pattern.
Select a GoF Pattern: Match the change point to the appropriate GoF category:
- Creational (object creation complexity): Builder, Factory Method, Abstract Factory, Prototype
- Structural (interface composition): Strategy, Adapter, Decorator, Facade, Proxy, Bridge
- Behavioral (communication & state): Observer, Command, State, Mediator
Checkpoint: The pattern must address the actual change point identified in step 1, not a hypothetical future need.
Implement with DRY: Extract shared behavior into well-named, single-responsibility components. Apply the duplication test: if the same logic appears in two places with only minor differences, it should be abstracted.
Checkpoint: Run the duplication test — no logic should exist in two places that would need identical changes.Validate with YAGNI: Review every abstraction and ask: "Is this solving a real problem, or am I guessing about the future?" Remove speculative layers, merge overly-generic abstractions, and prefer concrete types until composition genuinely requires an interface.
Checkpoint: Every class, interface, and pattern has at least one confirmed use case.
Implementation Patterns & Reference Guide
Pattern 1: Creational — Builder Pattern
The Builder pattern separates complex object construction from its representation. Use it when an object requires many configuration parameters (some optional), construction involves multiple steps, or you need fluent, readable creation that makes every option explicit.
# ❌ BAD — Telescoping constructor with 12 parameters is error-prone and unreadable
class DatabaseConfig:
def __init__(self, host: str, port: int, database: str,
username: str | None = None, password: str | None = None,
ssl: bool = False, ssl_cert_path: str | None = None,
pool_size: int = 10, pool_timeout: int = 30,
retry_attempts: int = 3, retry_delay: float = 1.0,
query_timeout: int = 60):
self.host = host
self.port = port
self.database = database
self.username = username
self.password = password
self.ssl = ssl
self.ssl_cert_path = ssl_cert_path
self.pool_size = pool_size
self.pool_timeout = pool_timeout
self.retry_attempts = retry_attempts
self.retry_delay = retry_delay
self.query_timeout = query_timeout
# Calling this is nearly impossible to read:
config = DatabaseConfig("localhost", 5432, "mydb", "admin", "secret",
True, "/certs/db.pem", 20, 45, 5, 2.0, 120)
# Which positional arg is pool_timeout? Impossible to tell.
# ✅ GOOD — Builder provides fluent, self-documenting construction
from dataclasses import dataclass, field
dataclass(frozen=True)
class DatabaseConfig:
"""Immutable database configuration."""
host: str
port: int
database: str
username: str | None = None
password: str | None = None
ssl: bool = False
pool_size: int = 10
pool_timeout: int = 30
retry_attempts: int = 3
query_timeout: int = 60
class DatabaseConfigBuilder:
"""Fluent builder for DatabaseConfig with validation."""
def __init__(self, host: str, port: int, database: str) -> None:
self._host = host
self._port = port
self._database = database
self._username: str | None = None
self._password: str | None = None
self._ssl: bool = False
self._pool_size: int = 10
self._pool_timeout: int = 30
self._retry_attempts: int = 3
self._retry_delay: float = 1.0
self._query_timeout: int = 60
def with_credentials(self, username: str, password: str) -> "DatabaseConfigBuilder":
"""Set authentication credentials."""
self._username = username
self._password = password
return self
def enable_ssl(self, enabled: bool = True) -> "DatabaseConfigBuilder":
"""Enable or disable SSL connection."""
self._ssl = enabled
return self
def with_pool(self, size: int = 10, timeout: int = 30) -> "DatabaseConfigBuilder":
"""Configure connection pool settings."""
if size <= 0:
raise ValueError("Pool size must be positive")
if timeout <= 0:
raise ValueError("Pool timeout must be positive")
self._pool_size = size
self._pool_timeout = timeout
return self
def with_retries(self, attempts: int = 3, delay: float = 1.0) -> "DatabaseConfigBuilder":
"""Configure retry behavior."""
if attempts < 0:
raise ValueError("Retry attempts cannot be negative")
self._retry_attempts = attempts
self._retry_delay = delay
return self
def with_timeout(self, seconds: int) -> "DatabaseConfigBuilder":
"""Set query timeout in seconds."""
if seconds <= 0:
raise ValueError("Query timeout must be positive")
self._query_timeout = seconds
return self
def build(self) -> DatabaseConfig:
"""Create the immutable configuration."""
return DatabaseConfig(
host=self._host,
port=self._port,
database=self._database,
username=self._username,
password=self._password,
ssl=self._ssl,
pool_size=self._pool_size,
pool_timeout=self._pool_timeout,
retry_attempts=self._retry_attempts,
query_timeout=self._query_timeout,
)
# Usage — self-documenting, impossible to misuse:
config = (DatabaseConfigBuilder("localhost", 5432, "mydb")
.with_credentials("admin", "secret")
.enable_ssl()
.with_pool(size=20, timeout=45)
.with_retries(attempts=5)
.with_timeout(120)
.build())
Why this works: The builder enforces validation at construction time, produces an immutable result, and every option is visible in the call chain — no positional argument guessing. This satisfies SRP (builder handles construction, config holds state) and is individually testable.
Pattern 2: Structural — Strategy Pattern with SOLID OCP
The Strategy pattern encapsulates interchangeable algorithms behind a common interface, replacing conditional branching with polymorphism. It directly implements the Open/Closed Principle: new strategies can be added without modifying the code that uses them.
# ❌ BAD — Conditional logic violates OCP; every new tax rule requires modifying this class
class TaxCalculator:
def calculate(self, amount: float, region: str) -> float:
if region == "us_california":
return amount * 0.0725
elif region == "us_new_york":
return amount * 0.08875
elif region == "eu_germany":
return amount * 0.19
elif region == "eu_france":
return amount * 0.20
elif region == "uk":
return amount * 0.20
elif region == "jp":
return amount * 0.10
elif region == "zero_rated":
return 0.0
raise ValueError(f"Unknown region: {region}")
# Adding a new region requires modifying this method — violates OCP.
# Testing requires covering every branch.
# Any change to one region's logic risks breaking others.
# ✅ GOOD — Strategy pattern makes tax rules open/closed and independently testable
from abc import ABC, abstractmethod
from dataclasses import dataclass
from typing import Protocol
class TaxRule(Protocol):
"""A tax rule that calculates tax for a given amount."""
def calculate_tax(self, amount: float) -> float: ...
class CaliforniaTaxRule:
"""7.25% tax for California."""
def calculate_tax(self, amount: float) -> float:
return round(amount * 0.0725, 2)
class NewYorkTaxRule:
"""8.875% tax for New York."""
def calculate_tax(self, amount: float) -> float:
return round(amount * 0.08875, 2)
class GermanyTaxRule:
"""19% VAT for Germany."""
def calculate_tax(self, amount: float) -> float:
return round(amount * 0.19, 2)
class ZeroTaxRule:
"""Zero tax for exempt transactions."""
def calculate_tax(self, amount: float) -> float:
return 0.0
@dataclass(frozen=True)
class TaxResult:
"""Immutable result of a tax calculation."""
amount: float
tax: float
total: float
@property
def effective_rate(self) -> float:
return self.tax / self.amount if self.amount > 0 else 0.0
class TaxCalculator:
"""Calculates tax by delegating to the configured strategy.
OCP: Adding a new tax rule requires only creating a new class.
DIP: TaxCalculator depends on TaxRule (abstraction), not concrete implementations.
"""
def __init__(self, rule: TaxRule) -> None:
self._rule = rule
def calculate(self, amount: float) -> TaxResult:
"""Calculate tax using the configured rule."""
if amount < 0:
raise ValueError("Amount cannot be negative")
tax = self._rule.calculate_tax(amount)
return TaxResult(amount=amount, tax=tax, total=round(amount + tax, 2))
# Usage — each region gets its own calculable, testable strategy:
# calculator = TaxCalculator(CaliforniaTaxRule())
# result = calculator.calculate(100.0) # TaxResult(amount=100.0, tax=7.25, total=107.25)
#
# Adding Japan tax — zero changes to TaxCalculator:
class JapanTaxRule:
"""10% consumption tax for Japan."""
def calculate_tax(self, amount: float) -> float:
return round(amount * 0.10, 2)
# calculator = TaxCalculator(JapanTaxRule())
...}{"filePath":"skills/coding/design-patterns-architecture/SKILL.md"}uptools to validate creativity using communications. All to be validated and acknowledge the shift from explicit promises to adaptive, optimistic actions. The solver observes multiple styles to give a clear answer. For this pathway, put forward logical constraint in all areas. The goal is deliberative strategy.
Constraints
MUST DO
- Validate all inputs at function boundaries before processing — guard clauses should fail early with descriptive errors
- Implement proper error handling that distinguishes between recoverable and unrecoverable failures
- Add comprehensive logging with structured context (correlation IDs, operation names, timing) for debugging and monitoring
- Write unit tests covering normal operations, edge cases, and error conditions before integrating the component
MUST NOT DO
- Do not silently swallow exceptions — always log or propagate errors with meaningful context
- Avoid unbounded resource allocation without limits (connection pools, memory buffers, thread counts)
- Never use hardcoded credentials, API keys, or secrets in source code
- Do not bypass input validation for perceived performance gains
Live References
Authoritative documentation links for this skill's domain. The model follows markdown links at load time to resolve external references and inline content.