English | 中文
jfoundry is a practical DDD framework for Java, built on jMolecules and designed for Hexagonal Architecture and Onion Architecture.
It helps business projects make domain modeling, architecture boundaries, and reliable integration executable in code. The core defines DDD concepts, architecture semantics, application contracts, domain events, persistence SPI, and messaging SPI without depending on a runtime framework. Spring, Quarkus, and Helidon assemble the same core through peer runtime integration modules.
DDD projects often lose their intended boundaries in implementation: domain code imports framework or ORM APIs, transaction ownership is unclear, repositories become generic query interfaces, and external events are not delivered reliably. jfoundry provides:
- jMolecules-based DDD, Hexagonal, Onion, and CQRS semantics.
- Explicit dependency direction across domain, application, infrastructure, and runtime integration.
- Reusable ArchUnit rules for executable architecture constraints.
- Optional production capabilities for persistence, message delivery, reliable messaging, transactions, and runtime assembly.
The domain model stays independent of Spring, ORM, HTTP, brokers, and database clients. Application contracts orchestrate use cases and define capability SPI; infrastructure implements technical adapters; runtime integrations assemble them.
runtime integration
-> application / infrastructure adapters
-> application contracts
-> domain
Dependencies point inward. This keeps runtime integrations outside the core rather than making a particular framework a requirement for every application.
domain-architecture-skills is the
Domain Architecture Plugin that complements JFoundry at design time. It guides an AI coding agent
from requirements through domain modeling and architecture decisions, then enters JFoundry only
when JFoundry is selected. It is installed separately and is not a runtime dependency or a
mandatory combined architecture.
See Adoption Readiness and Validated Scope for the evidence and boundaries of using the plugin together with JFoundry.
requirements -> domain modeling -> architecture decision -> optional jfoundry landing -> implementation handoff
| Area | Capability |
|---|---|
| Domain modeling | Aggregates, value objects, domain events, repository contracts, and domain exceptions |
| Architecture | Hexagonal and Onion semantics with ArchUnit rules |
| Application | Application services, transaction boundaries, CQRS, and domain-event orchestration |
| Persistence | Aggregate persistence contracts with JPA and MyBatis-Plus implementations |
| Message delivery | Runtime-neutral outbound transport contracts with explicit Kafka, RabbitMQ, and RocketMQ adapters |
| Reliable messaging | Transactional Outbox, Inbox idempotency, messaging, and serialization SPI |
| Runtime integration | Spring Framework and Spring Boot assembly; Quarkus and Helidon CDI/Jakarta Transactions, JPA, Outbox/Inbox, and REST Problem Details assembly |
- Architecture and modeling: start with Getting Started, then select an architecture style and review modeling conventions.
- Aggregate persistence: read Aggregate Persistence, then choose the peer implementation that fits the project: JPA or MyBatis-Plus.
- Message delivery: read Message Delivery to select a direct Kafka, RabbitMQ, RocketMQ, or application-owned transport adapter.
- Reliable messaging: read Reliable Messaging, then choose its JPA or MyBatis-Plus store from the corresponding JPA or MyBatis-Plus guide.
- Spring Boot: use Spring Boot Runtime Assembly for starter-based, conditional auto-configuration of selected capabilities; see the Spring Boot auto-configuration reference for its properties, conditions, and bean precedence.
- Quarkus: use Quarkus Runtime Integration for explicit extension composition, CDI transactions, REST Problem Details, domain-event dispatch, JPA-backed reliable messaging, Kafka and RabbitMQ delivery, and Native Image verification.
- Helidon MP: use Helidon MP Runtime Integration for explicit CDI/JTA, JPA, Outbox/Inbox, and REST Problem Details composition. Its Native Image support currently verifies CDI/Web only; Helidon Narayana JTA Native execution remains experimental upstream.
Every application imports the runtime-neutral BOM, then adds only the starters and capability implementations it requires. A Spring Boot, Quarkus, or Helidon application additionally imports its matching runtime BOM; runtime BOMs manage their platform ecosystems and do not replace the JFoundry BOM.
<dependencyManagement>
<dependencies>
<dependency>
<groupId>io.github.xfoundries</groupId>
<artifactId>jfoundry-dependencies</artifactId>
<version>${jfoundry.version}</version>
<type>pom</type>
<scope>import</scope>
</dependency>
</dependencies>
</dependencyManagement>// Money.java
import org.jfoundry.domain.valueobject.ValueObject;
import java.math.BigDecimal;
public record Money(BigDecimal amount, String currency) implements ValueObject {
}// OrderId.java
import org.jmolecules.ddd.types.Identifier;
public record OrderId(String value) implements Identifier {
}// Order.java
import org.jfoundry.domain.entity.agg.BaseAggregateRoot;
public final class Order extends BaseAggregateRoot<Order, OrderId> {
private Money total;
public Order(OrderId id, Money total) {
super(id);
this.total = total;
}
public void changeTotal(Money total) {
this.total = total;
}
}- Getting Started
- Adoption Readiness and Validated Scope
- Support Policy
- Supply-Chain Security
domain-architecture-skills
- Aggregate Persistence
- Message Delivery
- Reliable Messaging: Outbox And Inbox
- Application Transactions
- Distributed Locks
- Compatibility Matrix
- Maven Central Publishing
- Native Image verification status: review the scoped runtime and capability evidence together with the Compatibility Matrix; it is not a blanket support claim.
For the complete documentation structure, see the Documentation Index.
mvn validate
mvn test
mvn clean install