architecture-principles
npx machina-cli add skill kicchann/reqord/architecture-principles --openclawClean Architecture Principles
This skill provides language-agnostic Clean Architecture principles for designing maintainable, testable software systems.
When to Use This Skill
- Designing new feature architecture
- Reviewing layer boundaries and dependencies
- Evaluating dependency injection approaches
- Making decisions about abstraction placement
Core Concepts
Clean Architecture aims to create systems where:
- Business rules are independent of frameworks
- UI, database, and external services are interchangeable
- The system is testable without external dependencies
Quick Reference
Layer Structure (Inside -> Outside)
- Domain Layer - Business rules, entities, value objects (no dependencies)
- Application Layer - Use cases, application services, ports
- Presentation Layer - UI, controllers, view models
- Infrastructure Layer - Frameworks, databases, external APIs
Dependency Rule
Dependencies point inward only. Outer layers depend on inner layers, never the reverse.
Infrastructure -> Presentation -> Application -> Domain
^ ^ ^ ^
(outer) (inner)
Key Principles
- Dependency Inversion: Depend on abstractions, not concretions
- Interface Segregation: Small, focused interfaces
- Single Responsibility: Each layer has one reason to change
Resources
Read these in order for comprehensive understanding:
resources/dependency-inversion.md- Dependency Inversion Principleresources/layer-separation.md- Layer responsibilities and boundariesresources/reference-rules.md- Abstract reference rules for any language
Integration with Other Skills
- tdd-principles: Testability through proper layer separation
- review-standards: Architecture compliance checking
- For language-specific implementation, see app-level skills
Source
git clone https://github.com/kicchann/reqord/blob/main/plugins/reqord/skills/architecture-principles/SKILL.mdView on GitHub Overview
This skill provides language-agnostic Clean Architecture principles for designing maintainable, testable software systems. It emphasizes inward dependencies, clear layer boundaries, and reference rules to help review decisions and design new features.
How This Skill Works
Define concentric layers: Domain (innermost), Application, Presentation, Infrastructure. Dependencies point inward and abstractions allow outer layers to rely on inner ones; enforce layer boundaries with reference rules to improve testability and replaceability.
When to Use It
- Designing new feature architecture
- Reviewing layer boundaries and dependencies
- Evaluating dependency injection approaches
- Deciding where abstractions live
- Ensuring architectural decisions stay within layer boundaries
Quick Start
- Step 1: Map the system into Domain, Application, Presentation, and Infrastructure layers
- Step 2: Move business rules into Domain and define ports/interfaces in inner layers
- Step 3: Wire dependencies inward and use DI to connect outer layers to abstractions
Best Practices
- Keep the Domain layer free of framework dependencies
- Depend on abstractions, not concretions
- Enforce inward dependencies across all layers
- Define small, focused interfaces (Interface Segregation Principle)
- Regularly audit the dependency graph and DI wiring
Example Use Cases
- Design a new feature with Domain as the core and outer layers consuming via interfaces
- Review an existing module to confirm Infrastructure never penetrates Domain
- Introduce dependency injection to decouple repositories from use cases
- Refactor a monolithic service into Domain, Application, Presentation, and Infrastructure layers
- Create a reference rules doc to guide future architecture decisions
