ca-architecture-boundaries
Use when designing system architecture, drawing boundaries between business logic and infrastructure, or when changes touch many unrelated files. Triggers on: architecture design, dependency direction, separating business rules from database/UI/frameworks.
Best use case
ca-architecture-boundaries is best used when you need a repeatable AI agent workflow instead of a one-off prompt.
Use when designing system architecture, drawing boundaries between business logic and infrastructure, or when changes touch many unrelated files. Triggers on: architecture design, dependency direction, separating business rules from database/UI/frameworks.
Teams using ca-architecture-boundaries should expect a more consistent output, faster repeated execution, less prompt rewriting.
When to use this skill
- You want a reusable workflow that can be run more than once with consistent structure.
When not to use this skill
- You only need a quick one-off answer and do not need a reusable workflow.
- You cannot install or maintain the underlying files, dependencies, or repository context.
Installation
Claude Code / Cursor / Codex
Manual Installation
- Download SKILL.md from GitHub
- Place it in
.claude/skills/ca-architecture-boundaries/SKILL.mdinside your project - Restart your AI agent — it will auto-discover the skill
How ca-architecture-boundaries Compares
| Feature / Agent | ca-architecture-boundaries | Standard Approach |
|---|---|---|
| Platform Support | Not specified | Limited / Varies |
| Context Awareness | High | Baseline |
| Installation Complexity | Unknown | N/A |
Frequently Asked Questions
What does this skill do?
Use when designing system architecture, drawing boundaries between business logic and infrastructure, or when changes touch many unrelated files. Triggers on: architecture design, dependency direction, separating business rules from database/UI/frameworks.
Where can I find the source code?
You can find the source code on GitHub using the link provided at the top of the page.
SKILL.md Source
# Architecture Boundaries (Clean Architecture)
Operates at SYSTEM level (layers, boundaries, components). For MODULE level (interface depth, information hiding), use aposd-designing-deep-modules.
---
## SRP Is About Actors, Not "Doing One Thing"
"A module should be responsible to one, and only one, actor."
An actor is a group of users/stakeholders who request changes. If two actors share a class, a change for one can break the other.
```java
// BEFORE: One class serves three actors
class Employee {
Money calculatePay() { } // CFO's accounting team
String reportHours() { } // COO's HR team
void save() { } // CTO's DBA team
}
// AFTER: Separate class per actor
class EmployeeData { /* just data */ }
class PayCalculator {
Money calculatePay(EmployeeData e) { /* CFO */ }
}
class HourReporter {
String reportHours(EmployeeData e) { /* COO */ }
}
class EmployeeSaver {
void saveEmployee(EmployeeData e) { /* CTO */ }
}
// Optional: Facade for convenience
class EmployeeFacade {
// Delegates to actor-specific classes
}
```
**Test:** For each class, ask "who requests changes to this?" If the answer is more than one actor, split.
---
## DRY Within Actor Boundaries Only
Duplication across actor boundaries is safer than coupling.
If CFO's calculatePay and COO's reportHours both use the same regularHours helper, they appear duplicated — but they change for different reasons. Merging them couples two actors. When CFO's accounting rules change, COO's reports break.
**Rule:** DRY applies within a single actor's code. Across actors, prefer duplication over coupling.
---
## Dependency Rule
Dependencies point inward: Frameworks → Adapters → Use Cases → Entities.
Nothing in an inner circle can know anything about an outer circle. Business rules never import database, UI, or framework code. If business logic needs to call infrastructure, define an interface in the business layer and implement it in the infrastructure layer (dependency inversion).
---
## Separate Business Rules from Infrastructure
```java
// 1. Interface defined in business layer (where it's USED, not implemented)
public interface OrderRepository {
Order findById(String id);
void save(Order order);
}
// 2. Entity with Critical Business Rules (pure, no dependencies)
public class Order {
private Money total;
public Money calculateDiscount() {
if (total.isGreaterThan(1000))
return total.multiply(0.1);
return Money.ZERO;
}
}
// 3. Use Case orchestrates (does NOT contain business rules)
public class ProcessOrderUseCase {
private OrderRepository repository;
public OrderResponse execute(OrderRequest request) {
Order order = repository.findById(request.orderId);
Money discount = order.calculateDiscount();
order.applyDiscount(discount);
repository.save(order);
return new OrderResponse(order.getId(), order.getTotal());
}
}
// 4. Infrastructure implements interface (dependency inverted)
public class SqlOrderRepository implements OrderRepository {
public Order findById(String id) { /* SQL */ }
public void save(Order order) { /* SQL */ }
}
```
---
## Integration Checklist
When applying to an existing system:
### Phase 1: Identify
- [ ] Map actors (who requests changes?) → find SRP violations
- [ ] Identify Critical Business Rules (what makes/saves money?) → Entities
- [ ] List application workflows → Use Cases
- [ ] Find technical dependencies (DB, UI, frameworks) → Details to isolate
### Phase 2: Draw Boundaries
- [ ] Dependencies all point toward business rules?
- [ ] Can business logic run without infrastructure?
- [ ] Are changes proportional to scope, not shape?
### Phase 3: Verify
- [ ] SRP: Classes serving multiple actors?
- [ ] OCP: Simple extensions require modifying existing code?
- [ ] DIP: Business logic importing concrete infrastructure?
---
## Boundary Violation Detection
```bash
# Framework coupling in business logic
grep -r "import.*servlet\|import.*spring.*web\|import.*express" src/domain/
grep -r "import.*sql\|import.*mongoose\|import.*prisma" src/entities/
# ORM annotations in domain
grep -r "@Entity\|@Table\|@Column" src/domain/
# Type checking instead of polymorphism
grep -r "instanceof\|getType()\|typeof.*===" src/
```
---
## Chain
| After | Next |
|-------|------|
| Boundaries drawn | aposd-designing-deep-modules (module-level design) |
| SOLID violations found | cc-refactoring-guidance (safe restructuring) |Related Skills
whiteboarding-planning
Standard/Full planning pipeline for whiteboarding. Steps: discover, classify, explore, detail, save, check, confirm, handoff. Use when dispatched from whiteboarding command for Medium/Complex tasks. Triggers on 'planning pipeline', 'standard track', 'full track'.
welc-legacy-code
Use when facing untested legacy code, test harness problems, dependency issues, or time pressure. Triggers on: legacy code, no tests, can't test, afraid to change, need to modify untested code.
performance-optimization
Use when code is too slow, has performance issues, timeouts, OOM errors, high CPU/memory, or doesn't scale. Triggers on: profiler hot spots, latency complaints, needs optimization, critical path analysis.
code-clarity-and-docs
Use when reviewing code clarity, writing comments, checking documentation accuracy, or auditing AI-facing docs. Triggers on: naming, comments, documentation, README, CLAUDE.md.
clarify
Decompose user intent through structured brainstorming. Detects underspecification, ambiguity, and false premises through hypothesis-driven questioning. Use when a request is unclear, could have multiple valid interpretations, or critical details are missing.
cc-routine-and-class-design
Use when designing routines or classes, reviewing class interfaces, choosing between inheritance and containment, or evaluating routine cohesion. Also trigger when inheritance is used without LSP verification, or when design issues are present despite passing tests
cc-refactoring-guidance
Use when modifying existing code, improving structure without changing behavior, or deciding between refactor, rewrite, or fix-first.
cc-quality-practices
Use when planning QA, choosing review methods, designing tests, or debugging fails. Triggers on: defects found late, tests pass but production bugs, coverage disputes, review ineffective, spending excessive time debugging.
cc-pseudocode-programming
Use when designing routines, stuck on where to start coding, caught in compile-debug loops, or code works but you don't understand why. Triggers on: starting a new coding task
cc-defensive-programming
Use when auditing defensive code, designing barricades, choosing assertion vs error handling, or deciding correctness vs robustness strategy. Triggers on: empty catch blocks, missing input validation, assertions with side effects, wrong exception abstraction level, garbage in garbage out mentality, deadline pressure to skip validation, trusted source rationalization.
cc-control-flow-quality
Use when code has deep nesting (3+ levels), complex conditionals, loop design questions, high cyclomatic complexity (McCabe >10), or callback hell. Symptoms: arrow-shaped code, repeated conditions, confusing loop exits, lengthy if-else chains
aposd-verifying-correctness
Use after implementing code. Triggers on: is it done, ready to commit, verify correctness, did I miss anything, pre-commit check.