Architecture Review
Analyze Java project structure, packages, layers, and dependency boundaries.
Installation
- Make sure Claude is on your device and in your terminal.
Skills load from
~/.claude/skills/when Claude Code starts up β so you need it on your machine first. If you don't have it yet, install it once with the command below, then runclaudein any terminal to verify.One-time setupnpm i -g @anthropic-ai/claude-codeAlready have it? Skip ahead.
- Paste into Claude Code or into your terminal.
This copies the whole skill folder into
~/.claude/skills/architecture-review-decebals/β the SKILL.md plus any scripts, reference docs, or templates the skill ships with. Safe default: works for every skill.Faster alternative (instruction-only skills)
Skips the clone and grabs only the SKILL.md file. Don't use this if the skill ships Python scripts, reference markdowns, or asset templates β they won't be downloaded and the skill will fail when it tries to load them.
Quick install (SKILL.md only)Sign up to copy - Restart Claude Code.
Quit and reopen Claude Code (or any other agent that loads from
~/.claude/skills/). New skills are picked up on startup. - Just ask Claude.
Skills auto-activate when your request matches the skill's description β no slash command needed. Trigger phrases live in the skill's own frontmatter; you can read them in the βWhat this skill doesβ section above.
Prefer to read the source first? Open on GitHub.
When Claude uses it
Analyze Java project architecture at macro level - package structure, module boundaries, dependency direction, and layering. Use when user asks "review architecture", "check structure", "package organization", or when evaluating if a codebase follows clean architecture principles.
What this skill does
Architecture Review Skill
Analyze project structure at the macro level - packages, modules, layers, and boundaries.
When to Use
- User asks "review the architecture" / "check project structure"
- Evaluating package organization
- Checking dependency direction between layers
- Identifying architectural violations
- Assessing clean/hexagonal architecture compliance
Quick Reference: Architecture Smells
| Smell | Symptom | Impact |
|---|---|---|
| Package-by-layer bloat | service/ with 50+ classes | Hard to find related code |
| Domain β Infra dependency | Entity imports @Repository | Core logic tied to framework |
| Circular dependencies | A β B β C β A | Untestable, fragile |
| God package | util/ or common/ growing | Dump for misplaced code |
| Leaky abstractions | Controller knows SQL | Layer boundaries violated |
Package Organization Strategies
Package-by-Layer (Traditional)
com.example.app/
βββ controller/
β βββ UserController.java
β βββ OrderController.java
β βββ ProductController.java
βββ service/
β βββ UserService.java
β βββ OrderService.java
β βββ ProductService.java
βββ repository/
β βββ UserRepository.java
β βββ OrderRepository.java
β βββ ProductRepository.java
βββ model/
βββ User.java
βββ Order.java
βββ Product.java
Pros: Familiar, simple for small projects Cons: Scatters related code, doesn't scale, hard to extract modules
Package-by-Feature (Recommended)
com.example.app/
βββ user/
β βββ UserController.java
β βββ UserService.java
β βββ UserRepository.java
β βββ User.java
βββ order/
β βββ OrderController.java
β βββ OrderService.java
β βββ OrderRepository.java
β βββ Order.java
βββ product/
βββ ProductController.java
βββ ProductService.java
βββ ProductRepository.java
βββ Product.java
Pros: Related code together, easy to extract, clear boundaries Cons: May need shared kernel for cross-cutting concerns
Hexagonal/Clean Architecture
com.example.app/
βββ domain/ # Pure business logic (no framework imports)
β βββ model/
β β βββ User.java
β βββ port/
β β βββ in/ # Use cases (driven)
β β β βββ CreateUserUseCase.java
β β βββ out/ # Repositories (driving)
β β βββ UserRepository.java
β βββ service/
β βββ UserDomainService.java
βββ application/ # Use case implementations
β βββ CreateUserService.java
βββ adapter/
β βββ in/
β β βββ web/
β β βββ UserController.java
β βββ out/
β βββ persistence/
β βββ UserJpaRepository.java
β βββ UserEntity.java
βββ config/
βββ BeanConfiguration.java
Key rule: Dependencies point inward (adapters β application β domain)
Dependency Direction Rules
The Golden Rule
βββββββββββββββββββββββββββββββββββββββββββ
β Frameworks β β Outer (volatile)
βββββββββββββββββββββββββββββββββββββββββββ€
β Adapters (Web, DB) β
βββββββββββββββββββββββββββββββββββββββββββ€
β Application Services β
βββββββββββββββββββββββββββββββββββββββββββ€
β Domain (Core Logic) β β Inner (stable)
βββββββββββββββββββββββββββββββββββββββββββ
Dependencies MUST point inward only.
Inner layers MUST NOT know about outer layers.
Violations to Flag
// β Domain depends on infrastructure
package com.example.domain.model;
import org.springframework.data.jpa.repository.JpaRepository; // Framework leak!
import javax.persistence.Entity; // JPA in domain!
@Entity
public class User {
// Domain polluted with persistence concerns
}
// β Domain depends on adapter
package com.example.domain.service;
import com.example.adapter.out.persistence.UserJpaRepository; // Wrong direction!
// β
Domain defines port, adapter implements
package com.example.domain.port.out;
public interface UserRepository { // Pure interface, no JPA
User findById(UserId id);
void save(User user);
}
Architecture Review Checklist
1. Package Structure
- Clear organization strategy (by-layer, by-feature, or hexagonal)
- Consistent naming across modules
- No
util/orcommon/packages growing unbounded - Feature packages are cohesive (related code together)
2. Dependency Direction
- Domain has ZERO framework imports (Spring, JPA, Jackson)
- Adapters depend on domain, not vice versa
- No circular dependencies between packages
- Clear dependency hierarchy
3. Layer Boundaries
- Controllers don't contain business logic
- Services don't know about HTTP (no HttpServletRequest)
- Repositories don't leak into controllers
- DTOs at boundaries, domain objects inside
4. Module Boundaries
- Each module has clear public API
- Internal classes are package-private
- Cross-module communication through interfaces
- No "reaching across" modules for internals
5. Scalability Indicators
- Could extract a feature to separate service? (microservice-ready)
- Are boundaries enforced or just conventional?
- Does adding a feature require touching many packages?
Common Anti-Patterns
1. The Big Ball of Mud
src/main/java/com/example/
βββ app/
βββ User.java
βββ UserController.java
βββ UserService.java
βββ UserRepository.java
βββ Order.java
βββ OrderController.java
βββ ... (100+ files in one package)
Fix: Introduce package structure (start with by-feature)
2. The Util Dumping Ground
util/
βββ StringUtils.java
βββ DateUtils.java
βββ ValidationUtils.java
βββ SecurityUtils.java
βββ EmailUtils.java # Should be in notification module
βββ OrderCalculator.java # Should be in order domain
βββ UserHelper.java # Should be in user domain
Fix: Move domain logic to appropriate modules, keep only truly generic utils
3. Anemic Domain Model
// Domain object is just data
public class Order {
private Long id;
private List<OrderLine> lines;
private BigDecimal total;
// Only getters/setters, no behavior
}
// All logic in "service"
public class OrderService {
public void addLine(Order order, Product product, int qty) { ... }
public void calculateTotal(Order order) { ... }
public void applyDiscount(Order order, Discount discount) { ... }
}
Fix: Move behavior to domain objects (rich domain model)
4. Framework Coupling in Domain
package com.example.domain;
@Entity // JPA
@Data // Lombok
@JsonIgnoreProperties(ignoreUnknown = true) // Jackson
public class User {
@Id @GeneratedValue
private Long id;
@NotBlank // Validation
private String email;
}
Fix: Separate domain model from persistence/API models
Analysis Commands
When reviewing architecture, examine:
# Package structure overview
find src/main/java -type d | head -30
# Largest packages (potential god packages)
find src/main/java -name "*.java" | xargs dirname | sort | uniq -c | sort -rn | head -10
# Check for framework imports in domain
grep -r "import org.springframework" src/main/java/*/domain/ 2>/dev/null
grep -r "import javax.persistence" src/main/java/*/domain/ 2>/dev/null
# Find circular dependencies (look for bidirectional imports)
# Check if package A imports from B and B imports from A
Recommendations Format
When reporting findings:
## Architecture Review: [Project Name]
### Structure Assessment
- **Organization**: Package-by-layer / Package-by-feature / Hexagonal
- **Clarity**: Clear / Mixed / Unclear
### Findings
| Severity | Issue | Location | Recommendation |
|----------|-------|----------|----------------|
| High | Domain imports Spring | `domain/model/User.java` | Extract pure domain model |
| Medium | God package | `util/` (23 classes) | Distribute to feature modules |
| Low | Inconsistent naming | `service/` vs `services/` | Standardize to `service/` |
### Dependency Analysis
[Describe dependency flow, violations found]
### Recommendations
1. [Highest priority fix]
2. [Second priority]
3. [Nice to have]
Token Optimization
For large codebases:
- Start with
findto understand structure - Check only domain package for framework imports
- Sample 2-3 features for pattern analysis
- Don't read every file - look for patterns
Related skills
App Store Listing Audit
coreyhaines31
Analyze your app listing against best practices and get a prioritized optimization plan.
Co-Marketing Partnerships
coreyhaines31
Find ideal partners and plan joint marketing campaigns with other companies.
Cold Email Writer
coreyhaines31
Write B2B cold emails and follow-up sequences designed to get replies.
Community-Led Growth
coreyhaines31
Build and grow online communities to drive product adoption and customer loyalty.