CtrlK
BlogDocsLog inGet started
Tessl Logo

pantheon-ai/software-design-principles

Apply software design principles across architecture and implementation using deterministic decision workflows, SOLID checks, structural patterns, and anti-pattern detection; use when reviewing designs, refactoring modules, or resolving maintainability and coupling risks.

Review — 93%

Does it follow best practices?

Evaluation — 99%

↑ 1.01x

Agent success when using this tile

Validation — 11 / 11 Passed

Validation for skill structure

Overview
Skills
Evals
Files

usecase-single-responsibility.mdreferences/

title:
Each Use Case Has One Reason to Change
impact:
HIGH
impactDescription:
isolates change impact, enables parallel development
tags:
usecase, single-responsibility, cohesion, srp

Each Use Case Has One Reason to Change

Each use case class should orchestrate exactly one application-specific workflow. Combining multiple use cases creates coupling that forces unrelated changes together.

Incorrect (multiple use cases in one class):

class OrderService:
    def __init__(self, repo, payment, shipping, notification):
        self.repo = repo
        self.payment = payment
        self.shipping = shipping
        self.notification = notification

    def create_order(self, items, customer_id):
        # Use case 1: Create order
        order = Order.create(items, customer_id)
        self.repo.save(order)
        return order

    def process_payment(self, order_id, payment_method):
        # Use case 2: Process payment
        order = self.repo.find(order_id)
        self.payment.charge(order.total, payment_method)
        order.mark_paid()
        self.repo.save(order)

    def ship_order(self, order_id, address):
        # Use case 3: Ship order
        order = self.repo.find(order_id)
        tracking = self.shipping.create_shipment(order, address)
        order.mark_shipped(tracking)
        self.notification.send_shipped(order)
        self.repo.save(order)

    # Changes to shipping logic force retest of payment logic

Correct (separate use case classes):

class CreateOrderUseCase:
    def __init__(self, repo: OrderRepository):
        self.repo = repo

    def execute(self, command: CreateOrderCommand) -> OrderId:
        order = Order.create(command.items, command.customer_id)
        self.repo.save(order)
        return order.id


class ProcessPaymentUseCase:
    def __init__(self, repo: OrderRepository, payment: PaymentGateway):
        self.repo = repo
        self.payment = payment

    def execute(self, command: ProcessPaymentCommand) -> None:
        order = self.repo.find(command.order_id)
        self.payment.charge(order.total, command.payment_method)
        order.mark_paid()
        self.repo.save(order)


class ShipOrderUseCase:
    def __init__(
        self,
        repo: OrderRepository,
        shipping: ShippingService,
        notification: NotificationPort
    ):
        self.repo = repo
        self.shipping = shipping
        self.notification = notification

    def execute(self, command: ShipOrderCommand) -> TrackingNumber:
        order = self.repo.find(command.order_id)
        tracking = self.shipping.create_shipment(order, command.address)
        order.mark_shipped(tracking)
        self.notification.send_shipped(order)
        self.repo.save(order)
        return tracking

Benefits:

  • Changes to shipping don't affect payment tests
  • Teams can work on different use cases in parallel
  • Each use case has minimal dependencies

Reference: Clean Architecture - Use Cases

Install with Tessl CLI

npx tessl i pantheon-ai/software-design-principles

references

adapt-anti-corruption-layer.md

adapt-controller-thin.md

adapt-gateway-abstraction.md

adapt-mapper-translation.md

adapt-presenter-formats.md

anti-patterns-and-frameworks.md

bound-boundary-cost-awareness.md

bound-defer-decisions.md

bound-humble-object.md

bound-main-component.md

bound-partial-boundaries.md

bound-service-internal-architecture.md

comp-common-closure.md

comp-common-reuse.md

comp-reuse-release-equivalence.md

comp-screaming-architecture.md

comp-stable-dependencies.md

dep-acyclic-dependencies.md

dep-data-crossing-boundaries.md

dep-interface-ownership.md

dep-inward-only.md

dep-no-framework-imports.md

dep-stable-abstractions.md

detailed-examples.md

entity-encapsulate-invariants.md

entity-no-persistence-awareness.md

entity-pure-business-rules.md

entity-rich-not-anemic.md

entity-value-objects.md

frame-di-container-edge.md

frame-domain-purity.md

frame-logging-abstraction.md

frame-orm-in-infrastructure.md

frame-web-in-infrastructure.md

test-boundary-verification.md

test-layer-isolation.md

test-testable-design.md

test-tests-are-architecture.md

usecase-explicit-dependencies.md

usecase-input-output-ports.md

usecase-no-presentation-logic.md

usecase-orchestrates-not-implements.md

usecase-single-responsibility.md

usecase-transaction-boundary.md

SKILL-FULL.md

SKILL.md

tile.json