software-architecture

Guide software architecture design with Clean Architecture and domain-driven design principles.

Updated Dec 2, 2025
One-click install
npx skills add https://github.com/m16khb/claude-integration --skill software-architecture-m16khb
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: software-architecture
Source: https://github.com/m16khb/claude-integration/tree/main/.claude/skills/software-architecture
Command: npx skills add https://github.com/m16khb/claude-integration --skill software-architecture-m16khb

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

This Skill provides guidance on quality-focused software architecture rooted in Clean Architecture and DDD principles.

Core Features & Use Cases

  • Code style rules: Early returns, decomposition, and naming.
  • Best practices: Library-first approach, architecture boundaries, and anti-pattern avoidance.
  • Structural guidance: Separation of concerns and domain-driven design.
  • Usage Scenario: Design a module with clear boundaries and dependency rules.

Quick Start

Apply a layered architecture pattern to a new module with a domain entity and an application service.

Frequently Asked Questions about software-architecture

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I structure code with clean architecture and separation of concerns?

Clean architecture organizes code into distinct layers with clear boundaries—domain logic, application services, and infrastructure—where each layer has a specific responsibility. This separation prevents tight coupling, makes testing easier, and allows you to swap implementations without affecting core business logic.

What's the difference between domain-driven design and traditional layered architecture?

Domain-driven design (DDD) prioritizes modeling the business domain first, then organizing code around that model; layered architecture separates technical concerns (presentation, business logic, data). DDD is more strategy-focused for complex domains, while layered architecture is more practical for structure. Both can work together—DDD informs what goes into each layer.

How do I refactor a large component into smaller, maintainable parts?

Decompose by identifying distinct responsibilities within the component, extract each into a separate module or function, and establish clear dependencies between them. Use early returns to simplify logic, remove duplication, and apply naming conventions that reflect each part's purpose. Test each part independently to ensure boundaries work correctly.

When should I use a library-first approach instead of building custom code?

Prefer libraries when they solve a cross-cutting concern (logging, validation, HTTP handling) or a well-defined problem where the library is battle-tested and maintained. Building custom code is justified only when the library doesn't fit your domain boundaries or introduces unnecessary coupling to your core architecture.

How do I avoid common architecture anti-patterns in my codebase?

Anti-patterns emerge when layers leak into each other, naming obscures intent, or concerns mix together. Enforce boundaries by preventing lower layers from depending on higher ones, use explicit naming that reveals purpose, separate domain logic from infrastructure code, and review refactoring opportunities early to catch violations before they spread.

Do I need domain-driven design for small or medium-sized projects?

DDD principles like clear naming and separation of concerns scale down effectively; you don't need the full strategic methodology. Start with clean architecture basics—defined layers, single responsibilities, and testable boundaries—and introduce DDD concepts only when domain complexity justifies the overhead.