Java Hexagonal architecture boundary review
Help teams review and improve Hexagonal architecture boundaries in Java applications without coupling the guidance to Spring Boot, Quarkus, or Micronaut runtime wiring.
What is covered in this Skill?
- Domain independence: entities, value objects, domain services, and domain policies stay free of framework, persistence, web, messaging, and infrastructure APIs
- Application/use-case orchestration: use cases coordinate domain behavior through inbound or outbound ports without taking dependencies on concrete adapters
- Adapter and infrastructure boundaries: driving adapters call inbound ports, and driven adapters implement outbound ports
- Dependency direction checks: package, module, import, Maven module, and test evidence that adapters depend on the core rather than the core depending on adapters
- Optional architecture verification: ArchUnit-style rules for Hexagonal boundaries when architecture tests fit the project
- Evidence-backed remediation: findings cite concrete classes, imports, dependencies, packages, or tests and propose small boundary-preserving changes
Scope: Framework-agnostic architecture boundary review for Java projects. For Spring Boot, Quarkus, or Micronaut runtime wiring, defer to the matching framework skill. For adding ArchUnit or other Maven dependencies, defer to 111-java-maven-dependencies.
Constraints
Keep recommendations focused on architecture boundaries and dependency direction unless the user explicitly asks for framework runtime implementation. After editing this repository's XML sources, regenerate skills and verify the build.
- MANDATORY: Run
./mvnw compile or mvn compile before proposing Java or Maven changes in the same change set
- BOUNDARIES: Domain packages must not depend on application, adapter, infrastructure, framework, persistence, web, messaging, or dependency-injection APIs
- USE CASES: Application/use-case code may orchestrate domain behavior and depend on inbound/outbound ports, but must not depend on concrete adapter implementations
- ADAPTERS: Driving adapters call inbound ports and driven adapters implement outbound ports; adapters must not become shared domain logic or depend on each other unnecessarily
- ARCHUNIT OPTIONAL: Treat ArchUnit as an optional verification approach selected when it fits the project; do not require adding it before Hexagonal architecture guidance is useful
- DEPENDENCIES: Route Maven dependency evaluation, including ArchUnit dependency additions, to
111-java-maven-dependencies
- FRAMEWORK ROUTING: Defer Spring Boot, Quarkus, and Micronaut runtime wiring to the matching framework-specific skill without embedding direct framework skill links in this guidance
- VERIFY: Run
./mvnw clean verify or mvn clean verify before promoting changes
- EDGE CASE: If package layout, module boundaries, framework ownership, or persistence strategy is ambiguous and affects the review, ask a clarifying question before editing architecture-sensitive code
- EDGE CASE: Distinguish confirmed boundary violations from assumptions, conventions inferred from naming, and missing context
When to use this skill
- Review Hexagonal architecture
- Review ports and adapters boundaries
- Review architecture boundaries
- Enforce dependency direction
- Add ArchUnit architecture tests
- Detect infrastructure leakage in domain code
- Improve ports and adapters boundaries
Workflow
- Read reference and map the codebase
Read references/707-technologies-hexagonal-architecture.md and inspect packages, modules, imports, Maven modules, tests, and framework entry points before making claims about architecture boundaries.
- Identify ports, adapters, and dependency direction
Map domain, application/use-case, inbound ports, outbound ports, driving adapters, driven adapters, and infrastructure responsibilities; record the evidence used and mark unclear areas as assumptions.
- Review violations and propose boundary-preserving changes
Report concrete core-to-adapter dependency violations, framework or infrastructure leakage, adapter coupling, and misplaced behavior with small remediation steps aligned to the existing project structure.
- Recommend optional verification and route out-of-scope work
Suggest ArchUnit-style tests when useful, route dependency additions to 111-java-maven-dependencies, route framework runtime wiring to the matching framework skill, and summarize verification results.
Reference
For detailed guidance, examples, and constraints, see references/707-technologies-hexagonal-architecture.md.
1---2name: 707-technologies-hexagonal-architecture3description: Use when you need framework-agnostic Hexagonal architecture guidance for Java projects - ports and adapters boundaries, application core independence, driving and driven adapters, dependency direction, infrastructure leakage detection, optional architecture tests, and evidence-backed remediation. This should trigger for requests such as Review Hexagonal architecture; Review ports and adapters boundaries; Enforce dependency direction; Add ArchUnit architecture tests; Detect infrastructure leakage in domain code; Improve ports and adapters boundaries. Part of Plinth Toolkit4license: Apache-2.05---6# Java Hexagonal architecture boundary review
7
8Help teams review and improve **Hexagonal architecture** boundaries in Java applications without coupling the guidance to Spring Boot, Quarkus, or Micronaut runtime wiring.
9
10**What is covered in this Skill?**
11
12- Domain independence: entities, value objects, domain services, and domain policies stay free of framework, persistence, web, messaging, and infrastructure APIs
13- Application/use-case orchestration: use cases coordinate domain behavior through inbound or outbound ports without taking dependencies on concrete adapters
14- Adapter and infrastructure boundaries: driving adapters call inbound ports, and driven adapters implement outbound ports
15- Dependency direction checks: package, module, import, Maven module, and test evidence that adapters depend on the core rather than the core depending on adapters
16- Optional architecture verification: ArchUnit-style rules for Hexagonal boundaries when architecture tests fit the project
17- Evidence-backed remediation: findings cite concrete classes, imports, dependencies, packages, or tests and propose small boundary-preserving changes
18
19**Scope:** Framework-agnostic architecture boundary review for Java projects. For Spring Boot, Quarkus, or Micronaut runtime wiring, defer to the matching framework skill. For adding ArchUnit or other Maven dependencies, defer to `111-java-maven-dependencies`.
20
21## Constraints
22
23Keep recommendations focused on architecture boundaries and dependency direction unless the user explicitly asks for framework runtime implementation. After editing this repository's XML sources, regenerate skills and verify the build.
24
25- **MANDATORY**: Run `./mvnw compile` or `mvn compile` before proposing Java or Maven changes in the same change set
26- **BOUNDARIES**: Domain packages must not depend on application, adapter, infrastructure, framework, persistence, web, messaging, or dependency-injection APIs
27- **USE CASES**: Application/use-case code may orchestrate domain behavior and depend on inbound/outbound ports, but must not depend on concrete adapter implementations
28- **ADAPTERS**: Driving adapters call inbound ports and driven adapters implement outbound ports; adapters must not become shared domain logic or depend on each other unnecessarily
29- **ARCHUNIT OPTIONAL**: Treat ArchUnit as an optional verification approach selected when it fits the project; do not require adding it before Hexagonal architecture guidance is useful
30- **DEPENDENCIES**: Route Maven dependency evaluation, including ArchUnit dependency additions, to `111-java-maven-dependencies`
31- **FRAMEWORK ROUTING**: Defer Spring Boot, Quarkus, and Micronaut runtime wiring to the matching framework-specific skill without embedding direct framework skill links in this guidance
32- **VERIFY**: Run `./mvnw clean verify` or `mvn clean verify` before promoting changes
33- **EDGE CASE**: If package layout, module boundaries, framework ownership, or persistence strategy is ambiguous and affects the review, ask a clarifying question before editing architecture-sensitive code
34- **EDGE CASE**: Distinguish confirmed boundary violations from assumptions, conventions inferred from naming, and missing context
35
36## When to use this skill
37
38- Review Hexagonal architecture
39- Review ports and adapters boundaries
40- Review architecture boundaries
41- Enforce dependency direction
42- Add ArchUnit architecture tests
43- Detect infrastructure leakage in domain code
44- Improve ports and adapters boundaries
45
46## Workflow
47
481. **Read reference and map the codebase**
49
50Read `references/707-technologies-hexagonal-architecture.md` and inspect packages, modules, imports, Maven modules, tests, and framework entry points before making claims about architecture boundaries.
51
522. **Identify ports, adapters, and dependency direction**
53
54Map domain, application/use-case, inbound ports, outbound ports, driving adapters, driven adapters, and infrastructure responsibilities; record the evidence used and mark unclear areas as assumptions.
55
563. **Review violations and propose boundary-preserving changes**
57
58Report concrete core-to-adapter dependency violations, framework or infrastructure leakage, adapter coupling, and misplaced behavior with small remediation steps aligned to the existing project structure.
59
604. **Recommend optional verification and route out-of-scope work**
61
62Suggest ArchUnit-style tests when useful, route dependency additions to `111-java-maven-dependencies`, route framework runtime wiring to the matching framework skill, and summarize verification results.
63
64## Reference
65
66For detailed guidance, examples, and constraints, see [references/707-technologies-hexagonal-architecture.md](references/707-technologies-hexagonal-architecture.md).
gabrielmoreira