How do I install the Spring Boot Modulith skill?

Run npx skillmds@latest add tomevault-io/spring-boot-modulith in your terminal (requires Node.js), paste this page's agent-chat prompt into Claude, Cursor, or any MCP-connected agent, or download the SKILL.md file and copy it into your agent's skills directory.

Is Spring Boot Modulith safe to use?

This skill has not completed SkillMD's automated safety review yet. SkillMD never runs a skill's scripts for you; review the SKILL.md before installing.

Which AI agents work with Spring Boot Modulith?

This skill is tagged as working with Claude Code, Claude.ai, OpenAI Codex. SKILL.md is an open format, so most agents that read a skills directory can load it too.

Is Spring Boot Modulith free to use?

Yes. Installing skills from SkillMD is free, and the skill stays under its author's original license.

Who published Spring Boot Modulith?

tomevault-io (@tomevault-io) published this skill. Their other Agent Skills are listed on their SkillMD profile.

Spring Boot Modulith by tomevault-io

Name: Spring Boot Modulith
Author: tomevault-io

Spring Boot Modulith

Spring Modulith 2.0 implementation for bounded contexts in Spring Boot 4. Use when structuring application modules, implementing @ApplicationModuleListener for event-driven communication, testing with Scenario API, enforcing module boundaries, externalizing events to Kafka/AMQP, building a modular monolith, defining module dependencies, managing inter-module events, or organizing DDD modules as packages. Covers package-based module boundaries, named interfaces, event publication, and Scenario API testing. For architecture decisions, see domain-driven-design skill. Use when this capability is needed.

tomevault-io caaa307 2 files · 5.1 KB Updated Sep 17, 2026

File contents

Spring Modulith for Bounded Contexts

Implements DDD bounded contexts as application modules with enforced boundaries and event-driven communication.

Core Concepts

Concept	Description
Application Module	Package-based boundary = bounded context
Module API	Types in base package (public)
Internal	Types in sub-packages (encapsulated)
Events	Cross-module communication mechanism

Module Structure

src/main/java/
├── com.example/
│   └── Application.java              ← @SpringBootApplication
├── com.example.order/                ← Module: order
│   ├── OrderService.java             ← Public API
│   ├── OrderCreated.java             ← Public event
│   ├── package-info.java             ← @ApplicationModule config
│   └── internal/                     ← Encapsulated
│       ├── OrderRepository.java
│       └── OrderEntity.java
├── com.example.inventory/            ← Module: inventory
│   ├── InventoryService.java
│   └── internal/
└── com.example.shipping/             ← Module: shipping

Types in com.example.order = public API Types in com.example.order.internal = hidden from other modules

Quick Patterns

See EXAMPLES.md for complete working examples including:

Module Configuration with @ApplicationModule
Event Publishing with domain event records
Event Handling with @ApplicationModuleListener (Java + Kotlin)
Module Verification Test with PlantUML generation
Event Externalization for Kafka/AMQP

Spring Boot 4 / Modulith 2.0 Specifics

@ApplicationModuleListener combines @Async + @Transactional(REQUIRES_NEW) + @TransactionalEventListener(AFTER_COMMIT)
Event Externalization with @Externalized annotation for Kafka/AMQP
JDBC event log ensures at-least-once delivery

Detailed References

Examples: See EXAMPLES.md for complete working code examples
Troubleshooting: See TROUBLESHOOTING.md for common issues and Boot 4 migration
Workflow: See WORKFLOW.md for detailed step-by-step Modulith setup
Module Structure: See references/MODULE-STRUCTURE.md for package conventions, named interfaces, dependency rules
Event Patterns: See references/EVENTS.md for publishing, handling, externalization, testing with Scenario API

Related Skills

Need	Skill
DDD concepts	`domain-driven-design`
Data layer per module	`spring-boot-data-ddd`
Module event testing	`spring-boot-testing`
REST APIs for modules	`spring-boot-web-api`

Anti-Pattern Checklist

Anti-Pattern	Fix
Direct bean injection across modules	Use events or expose API
Synchronous cross-module calls	Use `@ApplicationModuleListener`
Module dependencies not declared	Add `allowedDependencies` in `@ApplicationModule`
Missing verification test	Add `ApplicationModules.verify()` test
Internal types in public API	Move to `.internal` sub-package
Events without data	Include all data handlers need

Critical Reminders

One module = one bounded context — Mirror DDD boundaries
Events are the integration mechanism — Not direct method calls
Verify in CI — ApplicationModules.verify() catches boundary violations
Reference by ID — Never direct object references across modules
Transaction per module — @ApplicationModuleListener ensures isolation

Converted and distributed by TomeVault — claim your Tome and manage your conversions.

---name: spring-boot-modulithdescription: Spring Modulith 2.0 implementation for bounded contexts in Spring Boot 4. Use when structuring application modules, implementing @ApplicationModuleListener for event-driven communication, testing with Scenario API, enforcing module boundaries, externalizing events to Kafka/AMQP, building a modular monolith, defining module dependencies, managing inter-module events, or organizing DDD modules as packages. Covers package-based module boundaries, named interfaces, event publication, and Scenario API testing. For architecture decisions, see domain-driven-design skill. Use when this capability is needed.---# Spring Modulith for Bounded ContextsImplements DDD bounded contexts as application modules with enforced boundaries and event-driven communication.## Core Concepts| Concept | Description ||---------|-------------|| **Application Module** | Package-based boundary = bounded context || **Module API** | Types in base package (public) || **Internal** | Types in sub-packages (encapsulated) || **Events** | Cross-module communication mechanism |## Module Structure```src/main/java/├── com.example/│ └── Application.java ← @SpringBootApplication├── com.example.order/ ← Module: order│ ├── OrderService.java ← Public API│ ├── OrderCreated.java ← Public event│ ├── package-info.java ← @ApplicationModule config│ └── internal/ ← Encapsulated│ ├── OrderRepository.java│ └── OrderEntity.java├── com.example.inventory/ ← Module: inventory│ ├── InventoryService.java│ └── internal/└── com.example.shipping/ ← Module: shipping```Types in `com.example.order` = public APITypes in `com.example.order.internal` = hidden from other modules## Quick PatternsSee [EXAMPLES.md](EXAMPLES.md) for complete working examples including:- **Module Configuration** with @ApplicationModule- **Event Publishing** with domain event records- **Event Handling** with @ApplicationModuleListener (Java + Kotlin)- **Module Verification Test** with PlantUML generation- **Event Externalization** for Kafka/AMQP## Spring Boot 4 / Modulith 2.0 Specifics- **@ApplicationModuleListener** combines `@Async` + `@Transactional(REQUIRES_NEW)` + `@TransactionalEventListener(AFTER_COMMIT)`- **Event Externalization** with `@Externalized` annotation for Kafka/AMQP- **JDBC event log** ensures at-least-once delivery## Detailed References- **Examples**: See [EXAMPLES.md](EXAMPLES.md) for complete working code examples- **Troubleshooting**: See [TROUBLESHOOTING.md](TROUBLESHOOTING.md) for common issues and Boot 4 migration- **Workflow**: See [WORKFLOW.md](WORKFLOW.md) for detailed step-by-step Modulith setup- **Module Structure**: See [references/MODULE-STRUCTURE.md](references/MODULE-STRUCTURE.md) for package conventions, named interfaces, dependency rules- **Event Patterns**: See [references/EVENTS.md](references/EVENTS.md) for publishing, handling, externalization, testing with Scenario API## Related Skills| Need | Skill ||------|-------|| DDD concepts | `domain-driven-design` || Data layer per module | `spring-boot-data-ddd` || Module event testing | `spring-boot-testing` || REST APIs for modules | `spring-boot-web-api` |## Anti-Pattern Checklist| Anti-Pattern | Fix ||--------------|-----|| Direct bean injection across modules | Use events or expose API || Synchronous cross-module calls | Use `@ApplicationModuleListener` || Module dependencies not declared | Add `allowedDependencies` in `@ApplicationModule` || Missing verification test | Add `ApplicationModules.verify()` test || Internal types in public API | Move to `.internal` sub-package || Events without data | Include all data handlers need |## Critical Reminders1. **One module = one bounded context** — Mirror DDD boundaries2. **Events are the integration mechanism** — Not direct method calls3. **Verify in CI** — `ApplicationModules.verify()` catches boundary violations4. **Reference by ID** — Never direct object references across modules5. **Transaction per module** — `@ApplicationModuleListener` ensures isolation---> Converted and distributed by [TomeVault](https://tomevault.io/claim/joaquimscosta) — claim your Tome and manage your conversions.

Frequently asked questions