architecture-conventions

Defines DDD hexagonal architecture rules for the ProvinceHow Spring Boot backend.

Updated Aug 10, 2026
One-click install
npx skills add https://github.com/LeeHyunWoo02/ProvinceHow --skill architecture-conventions-leehyunwoo02
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: architecture-conventions
Source: https://github.com/LeeHyunWoo02/ProvinceHow/tree/main/.claude/skills/architecture-conventions
Command: npx skills add https://github.com/LeeHyunWoo02/ProvinceHow --skill architecture-conventions-leehyunwoo02

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? When adding code to a DDD hexagonal (ports & adapters) Spring Boot codebase, developers struggle to decide which layer a new class belongs in, how to design ports, and how to keep bounded contexts decoupled. This Skill encodes the project's architecture rules so every new class, port, aggregate, and context follows the same structure. ## Core Features & Use Cases - Layer and dependency rules: Defines the domain/application/infrastructure/presentation four-layer structure, allowed dependency directions, and the rule that the domain layer has zero framework dependencies. - Bounded context guidance: Documents the six contexts (address, job, dwelling, infra, support, recommendation), the shared kernel value objects, and criteria for creating new contexts. - Port and aggregate design: Specifies out-port placement in domain/port, the no-in-port convention (application Service as the public entry point), aggregate ID-only references, and value object invariants. - Use Case: When adding a new JPA adapter or cache port, consult this Skill to place the interface in domain/port, implement it in infrastructure, and wire the correct transaction manager. ## Quick Start Use the architecture-conventions skill to decide which layer and package a new dwelling score cache adapter belongs in.

Frequently Asked Questions about architecture-conventions

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

FAQPage Schema
How do I structure a Spring Boot project with DDD hexagonal architecture?

Split each bounded context into domain, application, infrastructure, and presentation layers. Keep the domain layer free of Spring, JPA, and Redis dependencies, define out-port interfaces in domain/port, and implement them as adapters in infrastructure.

Where should repository interfaces go in a hexagonal architecture?

Place repository out-port interfaces in domain/port using only domain types in their signatures. The Spring Data JPA interface and the adapter implementing the port belong in infrastructure/persistence, keeping technology names out of the port.

Should aggregates reference other aggregates by object or by ID?

Reference other aggregates only by ID value objects, never by object references or JPA associations. This keeps aggregates small, avoids lazy-loading coupling, and ensures one transaction modifies only one aggregate.

Do I need use-case interfaces for every application service?

Not necessarily. This project omits in-port interfaces and lets controllers and other contexts call the application Service class directly, since each context has a single implementation and interfaces would only add indirection.

Why must @Transactional specify a transactionManager in a multi-datasource setup?

With two datasources, an unspecified @Transactional silently binds to whichever manager is @Primary, which can change. Always declare transactionManager explicitly, for example dataTransactionManager, to preserve atomicity and readOnly semantics.