ttulka/ddd-example-ecommerce-microservices

This system is an e-commerce platform built on a microservices architecture, comprising distinct services for catalog, cart, order, payment, delivery, and warehouse management. It facilitates the end-to-end shopping workflow, from product browsing and cart management to order placement, payment processing, and shipping dispatch. The frontend is a client-side single-page application that communicates with backend REST APIs, while internal service communication relies on domain events published via Redis or RabbitMQ.

A new Nginx-based reverse proxy has been introduced to route traffic to various backend services. The configuration proxies root requests to the portal service and directs specific paths (such as /catalog, /order, /cart, /payment, /delivery, /dispatching, and /warehouse) to their respective backend services, all running on port 8080.

reverseproxy · high confidence

The application-integration-spring-boot-starter now supports external message brokers for domain event publishing. By default, it uses local Spring application events, but users can switch to Redis (via the 'redis' profile) or RabbitMQ (via the 'rabbitmq' profile) to enable distributed messaging. This includes auto-configuration for the respective brokers, transactional event listeners, and JSON serialization for events. Configuration properties for database (Postgres) and Redis broker connections are also provided.

common/application-integration-spring-boot-starter · high confidence

This change introduces the Spring Boot application entry points (main classes) and corresponding integration tests for three microservices: billing/payment, shipping/delivery, and warehouse. Each service now has a dedicated \\*Application\ class configured with \@SpringBootConfiguration\, \@EnableAutoConfiguration\, and \@EnableAsync\, along with tests that verify the availability of REST endpoints (e.g., \/payment\, \/delivery\, \/warehouse/stock\) and basic data retrieval functionality.

billing/payment/application, shipping/delivery/application, warehouse/application · high confidence

This change introduces the foundational infrastructure and deployment artifacts for the e-commerce microservices architecture. It adds Kubernetes manifests defining the deployment and service configurations for backend services (catalog, order, cart, payment), the frontend portal, and a reverse proxy API gateway, along with infrastructure components for Redis and PostgreSQL. A Docker Compose file is provided to orchestrate the entire stack locally, including the reverse proxy and all microservices. Additionally, Gradle wrapper scripts and a \.gitignore\ file are added to support the multi-project build, while the README is updated to document these new deployment options.

(repo-wide) · high confidence

The portal module now includes its Spring Boot application entry point (PortalApplication) and a corresponding integration test suite. The application is configured to enable auto-configuration and asynchronous processing. The new tests verify that the application starts correctly on a random port and that the root index and the main JavaScript resource are served successfully.

portal/application · high confidence

This change introduces the initial Spring Boot application entry points and integration tests for three new microservices: Cart, Catalog, and Order. The Cart service exposes endpoints to add, remove, and empty shopping cart items. The Catalog service provides APIs to list categories, products, and products filtered by category. The Order service allows users to place new orders. Each service is configured with Spring Boot auto-configuration and async support, and includes tests verifying the core REST API behaviors.

sales/cart/application, sales/catalog/application, sales/order/application · high confidence

Adds the main entry point for the Shipping Dispatching microservice, bootstrapping a Spring Boot application with automatic configuration and asynchronous processing enabled. This change establishes the foundational application class and includes a basic integration test to verify that the application context starts successfully.

shipping/dispatching/application · high confidence

New custom elements have been added to the sales and shipping modules to handle specific UI interactions: a categories menu for navigation, a product list displaying items with stock status and buy buttons, an order form that aggregates items and triggers a placement event, and a delivery form for collecting shipping details with validation. These components provide the frontend interface for browsing products, managing cart actions, and submitting order and delivery information.

sales/catalog/webcomp, sales/order/webcomp, shipping/delivery/webcomp · high confidence

The Shipping and Warehouse services now expose new POST endpoints to support order fulfillment workflows. The Delivery service accepts a request to prepare a delivery for an order, requiring an order ID, recipient name, and address, and returns a 201 Created status upon success. The Warehouse service adds a bulk stock check endpoint that accepts a list of product IDs and returns an array of objects containing the product ID and the remaining stock amount for each, replacing the previous single-product lookup capability with a batch-oriented approach.

portal/use-cases/src, shipping/delivery/rest, warehouse/rest · high confidence

This change introduces three new Web Components to the sales cart interface: \cart-buy-button\ for adding items to the cart, \cart-item-list\ for displaying and removing cart items, and \cart-menu-link\ for showing the cart item count in the navigation. These components handle local UI interactions and dispatch custom events (\cart:add\, \cart:remove\, \cart:emptied\) to synchronize state across the application.

sales/cart/webcomp · high confidence

The system now decouples the delivery dispatching process from the core delivery logic by introducing an asynchronous event-driven mechanism. A new \DeliveryDispatchedListener\ listens for \DeliveryDispatched\ domain events and triggers the \DispatchDelivery\ use case asynchronously, ensuring that the dispatching action does not block the original transaction. This change is supported by a new \Dispatching\ interface in the dispatching domain and verified by unit tests for the listener.

shipping/delivery/listeners, shipping/dispatching/domain · high confidence

The logic for verifying whether a specific item exists in a cart has been updated to include the cart's unique identifier in the database query. Previously, the system checked for item presence based solely on product ID, title, and price, which could lead to false positives if an item with identical details existed in a different cart. Now, the check is scoped to the specific cart instance, ensuring accurate item tracking.

sales/cart/jdbc · high confidence

The CartController has been moved from the portal web module to the sales/cart/rest module and converted from a server-side rendered web controller to a REST controller. This change upgrades the application to Spring Boot 3, evidenced by the migration from javax.servlet to jakarta.servlet packages. The API behavior changes significantly: the cart listing now returns a JSON array of items instead of rendering a view, adding items requires a JSON body instead of form data and returns a 201 Created status, removing items uses a DELETE request instead of a GET redirect, and a new endpoint allows emptying the cart.

sales/cart/rest · high confidence

The catalog and order modules now provide REST endpoints instead of serving web pages. The catalog controller has moved to the sales layer and exposes JSON endpoints for listing categories (/catalog/categories), products (/catalog/products), and products by category (/catalog/products/{categoryUri}), while removing the previous warehouse stock checks and model-based view rendering. A new order controller exposes a POST /order endpoint that accepts a JSON payload to place orders, mapping the request to the underlying use-case.

sales/catalog/rest, sales/order/rest · high confidence

The Payment interface documentation has been refined to explicitly link thrown exceptions using Javadoc {@link} tags, improving clarity for developers handling payment states. Additionally, the PlaceOrder interface now requires a total amount parameter when placing an order, ensuring the order total is explicitly passed during the placement process.

billing/payment/domain, sales/order/domain · high confidence

The system has separated the delivery dispatching logic from the delivery state management. Previously, the \Delivery\ entity raised a \DeliveryDispatched\ event directly when dispatched; this behavior was removed from \DeliveryJdbc\. Instead, a new \Dispatching\ service (\DispatchingJdbc\) now handles the dispatch command, logs the action, and publishes the \DeliveryDispatched\ event. The \DispatchingSagaJdbc\ was updated to call this new \Dispatching\ service instead of the previous \DispatchDelivery\ use case. Consequently, the \DeliveryDispatchedListener\ in the warehouse module now subscribes to the event from the dispatching module, maintaining the decoupled architecture.

shipping/delivery/jdbc, shipping/dispatching/jdbc, warehouse/listeners · high confidence

The shipping module has been refactored to decouple the dispatching logic from the delivery process, allowing them to operate independently. In the delivery starter, the \DispatchDelivery\ bean is now backed by a new \DispatchDeliveryJdbc\ implementation, and the auto-configuration metadata has been migrated from the legacy \spring.factories\ file to the Spring Boot 3 standard \AutoConfiguration.imports\. Similarly, the dispatching starter now uses a dedicated \DispatchingJdbcConfig\ that injects a generic \Dispatching\ interface and an \EventPublisher\ instead of depending on delivery-specific classes, with its auto-configuration also updated to the new metadata format.

shipping/delivery/spring-boot-starter, shipping/dispatching/spring-boot-starter · high confidence

The \DispatchDelivery\ class has been converted from a concrete Spring-managed service (with transactional boundaries and dependency injection) into a pure domain interface. This change removes the implementation details of the dispatch use-case from this module, effectively decoupling the dispatching mechanism from the delivery domain logic. Additionally, Javadoc comments for \Delivery.prepare()\, \Delivery.dispatch()\, and \PrepareDelivery.prepare()\ have been updated to standardize exception documentation.

shipping/delivery/domain · high confidence

The DeliveryDispatched domain event has been moved from the shipping/delivery module to the shipping/dispatching module, reflecting a decoupling of dispatching logic from delivery. Additionally, the event class has been simplified by removing required constructor arguments and non-null constraints, allowing instances to be created with default values.

shipping/dispatching/events · high confidence

Domain event classes (PaymentCollected, OrderPlaced, DeliveryPrepared, GoodsFetched, GoodsMissed) have been updated to use Lombok's @NoArgsConstructor and @AllArgsConstructor instead of @RequiredArgsConstructor, and fields are no longer final or non-null. This change enables serialization frameworks (such as JSON serializers for Redis messages) to instantiate events using a no-argument constructor and set fields via setters or reflection, facilitating easier serialization and deserialization of event data.

(repo-wide) · high confidence

The DomainEvent interface now extends java.io.Serializable, allowing domain events to be serialized. This change supports the initialization of a Redis message broker, as Redis typically requires serializable payloads for message transmission.

common/events · high confidence

The billing/payment and warehouse starters now use the Spring Boot 2.7+ standard for auto-configuration by replacing the legacy \META-INF/spring.factories\ file with \META-INF/spring/org.springframework.boot.autoconfigure.AutoConfiguration.imports\. This change aligns the modules with the newer Spring Boot version (2.7.0) and ensures that the payment and warehouse components (controllers, JDBC configs, and listeners) are correctly registered via the new import mechanism.

billing/payment/spring-boot-starter, warehouse/spring-boot-starter, portal/spring-boot-starter · high confidence

The cart, catalog, and order starters have migrated their auto-configuration registration from the deprecated spring.factories file to the new Spring Boot 2.7+ AutoConfiguration.imports mechanism. Additionally, the REST controllers for each module (CartController, CatalogController, OrderController) are now explicitly registered in the auto-configuration imports, ensuring they are automatically available when the respective starters are on the classpath.

sales/cart/spring-boot-starter, sales/catalog/spring-boot-starter, sales/order/spring-boot-starter · high confidence

The portal's web presentation layer has been refactored from a server-side rendered model (Spring MVC controllers, Thymeleaf templates, and server-side layout advice) to a client-side single-page application architecture. Server-side controllers like OrderController and configuration classes like PortalWebConfig have been removed in favor of a new PortalController serving a static index.html and a suite of JavaScript modules (Application.js, CartPage.js, CatalogPage.js, OrderPage.js, etc.) that handle routing, rendering, and user interactions via custom elements. Corresponding Thymeleaf templates and i18n properties have been deleted, and the UI now relies on a new set of JavaScript services (cart, catalog, order, delivery, warehouse) to communicate with REST endpoints. The visual styling has also been updated with new CSS rules in layout.css.

portal/web · high confidence

The JDBC implementations for payments and product catalog queries now correctly pass pagination parameters in the order expected by the SQL statement. Previously, the code appended the start offset before the limit, but the SQL used \LIMIT ?,?\, causing the offset value to be interpreted as the limit. The code has been updated to append the limit first, then the start offset, and the SQL string now uses \LIMIT ? OFFSET ?\ to match this order, ensuring that pagination returns the correct range of results.

billing/payment/jdbc, sales/catalog/jdbc · high confidence

The application module's integration tests for the order workflow have been refactored to use a shared abstract base class (OrderWorkFlow) that defines the test scenarios for order shipping, stock deduction, and payment collection. The concrete test classes (OrderWorkFlowTest and OrderWorkFlowTestIT) now extend this base class, providing the server port configuration, which simplifies test maintenance and ensures consistent verification of the end-to-end order process.

application · high confidence

The project's Gradle wrapper has been updated to use Gradle 8.4, ensuring that builds are executed with this specific version of the build tool. This change standardizes the build environment and leverages the features and improvements available in Gradle 8.4.

gradle · high confidence

The build configuration has been updated to use Spring Boot 3.2.0 and the dependency management plugin 1.1.4, requiring Java 17. This upgrade aligns the project with modern Jakarta EE namespaces and the latest Spring Boot features.

(dependencies) · high confidence

Written by watchdog.canine.dev from the codebase's own history, inside the signed delivery this page is composed from.

• CAI 44 → 36 (-8.2)
• Rubric changed (rubric-2026.08.17 → rubric-2026.09.15) — scores are not directly comparable.

• Code Health 63 → 69 (+6.3)
• Architecture 100 → 94 (-6.3)
• Maturity 69 → 69 (+0.0)
• Readiness 23 → 23 (-0.3)
• Security 56 → 66 (+9.9)
• Accessibility 23 (new)

• Coverage not included — suite not readable by the collector
• Dependency hygiene not measured — no supported dependency manifest was read
• High IaC: KSV-0014 (1-infrastructure.k8s.yml)
• High IaC: KSV-0014 (2-backend-services.k8s.yml)
• High IaC: KSV-0118 (1-infrastructure.k8s.yml)
• High IaC: KSV-0118 (2-backend-services.k8s.yml)
• High IaC: KSV-0118 (3-frontend-portal.k8s.yml)
• High IaC: KSV-0118 (4-api-gateway.k8s.yml)
• Medium IaC: KSV-0001 (1-infrastructure.k8s.yml)
• Medium IaC: KSV-0001 (2-backend-services.k8s.yml)
• Medium: security finding (details withheld)
• Medium: security finding (details withheld)
• Medium: security finding (details withheld)
• Medium: security finding (details withheld)
• Medium: security finding (details withheld)
• Medium: security finding (details withheld)
• Medium: security finding (details withheld)
• Medium: security finding (details withheld)
• Medium: security finding (details withheld)
• No admission-control policy
• …and 4 more

• Coverage not measured — no coverage collector is wired up
• Dependency hygiene PARTLY measured — Maven/Gradle declarations read, no dependency graph resolved
• Documentation: no installation or build instructions (README.md)
• Documentation: no usage examples (README.md)
• Duplicated block (11 lines × 12) (billing/payment/domain/src/main/java/com/ttulka/ecommerce/billing/payment/PaymentId.java)
• Duplicated block (11 lines × 3) (sales/cart/domain/src/main/java/com/ttulka/ecommerce/sales/cart/item/Title.java)
• Duplicated block (5 lines × 2) (sales/order/jdbc/src/main/java/com/ttulka/ecommerce/sales/order/jdbc/FindOrdersJdbc.java)
• Duplicated block (7 lines × 2) (sales/catalog/jdbc/src/main/java/com/ttulka/ecommerce/sales/catalog/jdbc/FindCategoriesJdbc.java)
• Duplicated block (8 lines × 2) (billing/payment/jdbc/src/main/java/com/ttulka/ecommerce/billing/payment/jdbc/PaymentsJdbc.java)
• Duplicated block (9 lines × 2) (billing/payment/jdbc/src/main/java/com/ttulka/ecommerce/billing/payment/jdbc/PaymentsJdbc.java)
• High IaC: KSV-0014 (1-infrastructure.k8s.yml)
• High IaC: KSV-0014 (1-infrastructure.k8s.yml)
• High IaC: KSV-0014 (2-backend-services.k8s.yml)
• High IaC: KSV-0014 (2-backend-services.k8s.yml)
• High IaC: KSV-0014 (2-backend-services.k8s.yml)
• High IaC: KSV-0014 (2-backend-services.k8s.yml)
• High IaC: KSV-0014 (2-backend-services.k8s.yml)
• High IaC: KSV-0014 (2-backend-services.k8s.yml)
• High IaC: KSV-0014 (2-backend-services.k8s.yml)
• High IaC: WD-COMPOSE-0002 (docker-compose.yml)
• …and 383 more

Written by watchdog.canine.dev from the codebase's own history, inside the signed delivery this page is composed from.

ttulka/ddd-example-ecommerce-microservices was measured the same way every project in this corpus was: the same rubric, at a pinned commit, with the result published in full. Point a surveyor at a repository you know and see whether you agree with it.