Review Guide

This page helps reviewers inspect the repository quickly and intentionally. It gives different paths for recruiters, hiring managers, engineering managers, and hands-on engineers depending on how much time they have.

Suggested Review Paths

Key Links

• Dashboard
• User Guide
• Architecture
• Business Flow
• Trade-offs
• Testing
• CI and Pages
• Architecture Decision Records
• OpenAPI UI
• OpenAPI JSON
• JavaDoc
• Coverage Report
• HTML Test Report

Recruiter / HR Review

Start with the dashboard and README. The important signal is not that this is a large system, but that it is organized like a serious backend project: clear purpose, visible CI, public documentation, generated API reference, and a small but realistic e-commerce domain.

Look for:

• Java 21 and Spring Boot 4.x backend stack
• Modular monolith architecture rather than a toy single-package CRUD app
• GitHub Actions CI badge on the README
• Public GitHub Pages documentation
• Generated API, JavaDoc, coverage, and test reports

Engineering Manager Review

Read the architecture, business flow, trade-offs, and ADR index. This path shows how the project balances engineering discipline with scope control.

Look for:

• Clear module ownership across catalog, orders, payment, shared-kernel, and ecommerce-app
• Order placement flow from API call to stock reservation to payment event handling
• Explicit trade-offs explaining why the project avoids microservices and distributed messaging
• Testing strategy across unit, API, integration, and architecture tests
• CI that publishes useful reviewer-facing artifacts instead of only running tests

Senior Engineer / Architect Review

Inspect the source modules and tests. The strongest architecture signals are enforceable boundaries, narrow shared abstractions, internal Spring eventing, Flyway-managed persistence, and Testcontainers-backed integration tests.

Focus areas:

• shared-kernel: intentionally small shared abstractions such as domain events and exception base types.
• catalog: product ownership, stock reservation rules, read projections, and Redis-backed query caching.
• orders: order placement, idempotency-key handling, order lookup, and OrderPlacedEvent publication.
• payment: listener for OrderPlacedEvent, simulated authorization, and persisted payment attempts.
• ecommerce-app: Spring Boot bootstrap, REST error handling, Flyway migrations, OpenAPI configuration, and runtime wiring.
• coverage-report: build-only aggregate JaCoCo reporting module.

Files and areas worth checking:

• ArchUnit rules under ecommerce-app/src/test/java
• integration tests under ecommerce-app/src/test/java
• Flyway migrations under ecommerce-app/src/main/resources/db/migration
• OpenAPI configuration in ecommerce-app/src/main/resources/openapi.yaml
• package-level JavaDoc in module source packages

What To Look For In Tests

The test suite is meant to prove behavior and architecture, not only line coverage.

• Unit tests cover stock reservation, insufficient stock, order placement validation, idempotent retry handling, and payment behavior.
• API and integration tests exercise order placement, product queries, OpenAPI exposure, persistence, Flyway migrations, Redis caching, and payment event handling.
• Testcontainers starts PostgreSQL and Redis for realistic integration coverage.
• ArchUnit validates module boundaries and forbidden dependencies.
• The coverage report gives a quick health check, while the HTML test report shows executed test classes and integration-test status.

Hands-on Local Review

Use the User Guide for the operational workflow. A deep-dive reviewer should run mvn clean verify with Docker available, start the application, exercise the public API, and compare observed behavior with the OpenAPI reference and integration tests.

What This Project Is Not

This is a portfolio-quality, production-minded modular monolith. It is not a full production commerce platform.

It intentionally does not include:

• microservices
• Kafka or RabbitMQ
• Kubernetes
• distributed transactions
• external cloud deployment
• full production authentication and authorization

Those omissions are deliberate scope choices. The project focuses on clear backend boundaries, persistence discipline, testability, documentation, and CI/CD maturity without adding distributed-system complexity that the domain does not need.

Final Recommendation

For a quick review, check the dashboard and trade-offs first. For a technical review, inspect module boundaries and tests next. For a hands-on review, run mvn clean verify with Docker available and then exercise the API locally.