Senior backend portfolio

Spring Modulith Order Platform

A production-oriented modular monolith for order management. It demonstrates Spring Modulith boundaries, contract-first REST APIs, PostgreSQL persistence, domain events, architecture tests and generated documentation without distributed-system theater.

OpenAPI Documentation User Guide GitHub Repository

Architecture

A modular monolith with explicit boundaries.

The application keeps one deployment unit and uses Spring Modulith to make module relationships visible and enforceable. Cross-module collaboration goes through named API packages or domain events.

Inside each module, the project follows a pragmatic ports-and-adapters style: domain logic stays framework-independent, application services orchestrate use cases, and infrastructure contains persistence adapters.

Orders

Synchronous named APIs

Customers

Pricing

OrderCreatedEvent

Payments

PaymentAuthorizedEvent

Notifications

Module boundaries

Small public APIs, private implementation details.

Each module owns a narrow business capability. JPA entities stay in infrastructure packages, while public module APIs expose intentional records and interfaces.

identity

Customers

Registers customers and exposes customer lookup for order validation.

catalog

Pricing

Reads active catalog prices and calculates deterministic quotes.

workflow

Orders

Coordinates customer validation, pricing, persistence and order events.

state

Payments

Prepares pending payments after order commit and authorizes matching amounts.

events

Notifications

Records notification intents created from order and payment events.

contract

Generated API

Generated REST interfaces and DTOs stay at the API boundary.

Quality gates

Verification is part of the build, not a checklist in prose.

The repository favors behavior-focused tests and build-time artifact checks over decorative coverage targets.

Architecture tests ApplicationModules.verify() validates Spring Modulith boundaries, and ArchUnit guards domain and application dependencies.
REST integration tests Happy paths, validation failures, not-found responses, business rules, persistence and event side effects run against PostgreSQL.
Generated documentation Maven assembles and verifies the User Guide, JaCoCo, Javadoc, OpenAPI HTML, OpenAPI JSON and Pages artifact.
Deployment checks CI validates Docker Compose and builds the Docker image after tests pass.

Generated documentation

Published Pages are assembled from Maven outputs.

Maintained site sources live under src/site. Maven copies the landing page, User Guide and shared assets alongside generated reports in target/pages.

User Guide Local setup, API workflow, architecture, quality gates and troubleshooting. OpenAPI Documentation HTML contract reference generated from the OpenAPI source. OpenAPI JSON The published machine-readable REST contract. Javadoc Public API and domain documentation generated by Maven. JaCoCo Coverage Coverage report for non-generated project code. GitHub Repository Source, CI workflow, Dockerfile and documentation.

Local development

Run the same verification path locally.

PostgreSQL is the development and test database. H2 is intentionally excluded so schema behavior stays realistic.

docker compose up -d
./mvnw clean verify
./mvnw spring-boot:run

CI/CD

One Maven verification, then publish only generated Pages.

The workflow keeps CI direct: no matrix builds, no duplicated Maven runs, and no generated reports committed to Git.

Verify once Set up Java 21 with Maven cache and run ./mvnw -B -ntp clean verify.
Check artifacts Fail if the site assets, User Guide, coverage, Javadoc, OpenAPI or Pages outputs are missing.
Package and publish Validate Docker Compose, build the image and deploy only target/pages.