Exécutez n'importe quel Skill dans Manus
en un clic

Exécutez n'importe quel Skill dans Manus en un clic

backend-modulith-boundaries

Étoiles635

Forks136

Mis à jour14 juin 2026 à 22:07

Use when backend changes risk crossing feature boundaries, changing exported `api/` surfaces, or violating Spring Modulith dependency expectations in Iced Latte.

Installation

Installer avec Codex ou Claude Copiez ce prompt, collez-le dans Codex, Claude ou un autre assistant, puis laissez-le vérifier la page du skill et l'installer pour vous.

Exécuter dans Manus

Source

Sunagatov

Sunagatov/Iced-Latte

Ouvrir le dépôt GitHub Voir les dépôts du créateur

Téléchargement

Exécuter dans Manus

Métiers associésSOC

Basé sur la classification professionnelle SOC

Développeurs de logicielsProfessions informatiques et mathématiques·SOC 15-1252

SKILL.md

readonly

name	backend-modulith-boundaries
description	Use when backend changes risk crossing feature boundaries, changing exported `api/` surfaces, or violating Spring Modulith dependency expectations in Iced Latte.

Backend Modulith Boundaries

The modular-monolith structure is an architectural contract, not just packaging style.

Read Order

AGENTS.md
docs/architecture/feature-packaging.md
The smallest relevant feature packages and public api/ surfaces

Core Rules

Keep feature internals private by default.
Export only small intentional contracts from feature api/ packages.
Avoid direct dependencies on another feature’s repositories, entities, or service internals.
Do not move generated HTTP-edge DTOs into public module contracts.

Smell Checks

Is a feature reaching through another feature’s internals instead of a public API?
Is api/ leaking implementation classes?
Would this change make future feature extraction harder?

Verification

Run the narrowest relevant tests first.
If the repo has existing modularity tests for the touched area, include them when the boundary risk is real.

Plus depuis ce dépôt

même dépôt

api-and-interface-design

Sunagatov/Iced-Latte

Guides stable API and interface design. Use when designing APIs, module boundaries, or any public interface. Use when creating REST or GraphQL endpoints, defining type contracts between modules, or establishing boundaries between frontend and backend.

2026-06-14635

backend-feature-packaging

Sunagatov/Iced-Latte

Use when deciding where backend code should live in Iced Latte, especially feature ownership, `api/` boundaries, `common` vs feature placement, or cross-feature module dependencies in the modular monolith.

2026-06-14635

backend-liquibase-migrations

Sunagatov/Iced-Latte

Use when adding or changing database schema, Liquibase changelogs, SQL migration files, rollout order, or schema-backed backend behavior in Iced Latte backend.

2026-06-14635

backend-openapi-contract-changes

Sunagatov/Iced-Latte

Use when changing public backend API behavior, OpenAPI-owned request or response shapes, generated DTO boundaries, endpoint contracts, or compatibility rules in Iced Latte backend.

2026-06-14635

backend-security-auth-boundaries

Sunagatov/Iced-Latte

Use when changing backend JWT auth, sessions, Google OAuth, security filters, auth endpoints, authentication or authorization rules, or security-owned module boundaries in Iced Latte.

2026-06-14635

backend-testcontainers-routing

Sunagatov/Iced-Latte

Use when choosing backend verification for changes that touch integration tests, PostgreSQL, Redis, Kafka, or any test flow that depends on Testcontainers in Iced Latte.

2026-06-14635

name	backend-modulith-boundaries
description	Use when backend changes risk crossing feature boundaries, changing exported `api/` surfaces, or violating Spring Modulith dependency expectations in Iced Latte.

Backend Modulith Boundaries

The modular-monolith structure is an architectural contract, not just packaging style.

Read Order

AGENTS.md
docs/architecture/feature-packaging.md
The smallest relevant feature packages and public api/ surfaces

Core Rules

Keep feature internals private by default.
Export only small intentional contracts from feature api/ packages.
Avoid direct dependencies on another feature’s repositories, entities, or service internals.
Do not move generated HTTP-edge DTOs into public module contracts.

Smell Checks

Is a feature reaching through another feature’s internals instead of a public API?
Is api/ leaking implementation classes?
Would this change make future feature extraction harder?

Verification

Run the narrowest relevant tests first.
If the repo has existing modularity tests for the touched area, include them when the boundary risk is real.