ddd:software-architecture

Guides software architecture and code design using Clean Architecture and Domain-Driven Design principles.

Updated Jun 8, 2026
One-click install
npx skills add https://github.com/Avistian/nba --skill ddd-software-architecture-avistian
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: ddd:software-architecture
Source: https://github.com/Avistian/nba/tree/main/.cursor/skills/software-architecture
Command: npx skills add https://github.com/Avistian/nba --skill ddd-software-architecture-avistian

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? It helps developers avoid common architectural mistakes such as tangled business logic, generic naming, and reinventing existing solutions by enforcing Clean Architecture and Domain-Driven Design rules during coding and design work. ## Core Features & Use Cases - Architecture Guidance: Applies DDD and Clean Architecture principles, separating domain entities from infrastructure and keeping business logic framework-independent. - Code Style Rules: Enforces early returns, function and file size limits, arrow functions, and domain-specific naming instead of generic utils/helpers modules. - Library-First Decision Making: Directs evaluation of existing libraries and SaaS solutions before writing custom code, with clear criteria for when custom code is justified. - Use Case: When designing a new order-processing module, use this Skill to structure bounded contexts, name components like OrderCalculator instead of utils, and decide whether to adopt an existing library or write custom logic. ## Quick Start Ask the assistant to review or design your module's architecture following Clean Architecture and DDD principles with proper naming and separation of concerns.

Frequently Asked Questions about ddd:software-architecture

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

FAQPage Schema
How do I apply Clean Architecture and DDD principles to my code?▼

Separate domain entities from infrastructure concerns, keep business logic independent of frameworks, and define isolated use cases. Use ubiquitous language and bounded context naming so each module has a single clear purpose.

When should I write custom code instead of using a library?▼

Write custom code only for domain-specific business logic, performance-critical paths, security-sensitive code, or when existing solutions fail evaluation. Otherwise prefer established libraries, such as cockatiel for retry logic instead of a custom implementation.

What naming conventions should I avoid in software projects?▼

Avoid generic names like utils, helpers, common, and shared, which become dumping grounds for unrelated functions. Use domain-specific names such as OrderCalculator, UserAuthenticator, or InvoiceGenerator that reflect bounded contexts.

How long should functions and files be for maintainable code?▼

Keep functions under 50 lines and files under 200 lines when possible. Decompose components longer than 80 lines into smaller units, and split files exceeding 200 lines into multiple focused files.

What are common software architecture anti-patterns to avoid?▼

Avoid mixing business logic with UI components, putting database queries in controllers, and NIH syndrome such as building custom auth instead of Auth0 or Supabase. Also avoid deep nesting beyond three levels and unstructured error handling.