pawelkaczor/ddd-leaven-akka-v2

This system is a sample e-commerce application built with Scala, Akka, and Event Sourcing, organized into distinct subsystems for Sales, Invoicing, Shipping, and Headquarters. It implements a CQRS architecture where write-back services manage domain aggregates like reservations and shipments via an Event Store, while read-front services expose HTTP APIs backed by SQL view stores. The platform includes comprehensive tooling for local development, stress testing, and end-to-end validation of the order lifecycle.

48 changes.

The project was restructured from a flat layout into distinct business subsystems (Sales, Invoicing, Shipping, Headquarters), each implementing a reactive DDD architecture with separate write-back, read-back, and read-front services. This period focused on building the core domain aggregates, establishing CQRS projections to SQL view stores, and configuring the Akka cluster and Event Store persistence for each module. Comprehensive testing infrastructure, including Vagrant-based end-to-end environments and stress tests, was introduced to validate the distributed system.

6 changes.

This period focused on implementing the end-to-end order lifecycle through a new Order Process Manager saga in the Headquarters service, which orchestrates interactions between sales, invoicing, and shipping domains. The work included introducing reservation lifecycle management in the sales module, adding Kamon monitoring for observability, and establishing comprehensive test coverage for the new saga behaviors.

New entry-point applications (SalesViewUpdateApp and ShippingViewUpdateApp) have been added to the read-back modules for the Sales and Shipping subsystems. These applications initialize the Akka system and start the respective view-update services (SalesViewUpdateService and ShippingViewUpdateService) backed by a SQL view store configured with the Postgres JDBC profile, enabling the read-side projections to start as standalone bootable units.

sales/read-back/src/main/scala/ecommerce/sales/app, shipping/read-back/src/main/scala/ecommerce/shipping/app · high confidence

The sales read-back view now persists reservation state to a relational database using Slick. A new \ReservationDao\ manages the \reservations\ table, storing reservation ID, client ID, status, and creation date, while a \ReservationProjection\ listens for domain events (created, confirmed, canceled, closed) to keep the read-model in sync.

sales/read-back/src/main/scala/ecommerce/sales/view · high confidence

A new tutorial index page has been added to the documentation, providing an overview of the Reactive DDD with Akka sample e-commerce system. This page details the system's architecture, including its use of Akka, Akka HTTP, Akka Persistence, and Event Store, and outlines the subsystems (Sales/Reservation, Invoicing, Shipping, Headquarters) and the ordering process. It also describes the application structure (write/read back/front) and provides links to guides for running, testing, and monitoring the system.

tutorial · high confidence

The sales-write-back service now includes a new monitoring configuration and startup runner. A reference configuration file defines Kamon metrics with a 3-second tick interval and StatsD reporting to localhost:8125, while a new Scala runner ensures Kamon is properly initialized and shut down with the application lifecycle.

monitoring · high confidence

This change introduces the initial configuration files for the read-back service, establishing how it connects to the event store and manages logs. The \eventstore.conf\ file defines the connection details for the event store, including host, port, and credentials, with support for environment variable overrides. The \application.conf\ file configures Akka logging to use SLF4J and sets the default log level to DEBUG, while \logback.xml\ defines the console logging pattern and sets the root log level to DEBUG (configurable via the \ECOMMERCE\_LOG\_LEVEL\ environment variable), with specific loggers for Slick and event store TCP set to INFO.

shipping/read-back/src/main/resources · high confidence

The sales-write-back service is now configured with a new set of resource files that define its runtime behavior. It binds to host and port 9101 (overridable via environment variables) and joins an Akka cluster using configurable seed nodes. The service connects to an EventStore database at 127.0.0.1:1113 with default credentials (also overridable via environment variables) and uses EventStore for both journal and snapshot persistence. Logging is set up via Logback with a configurable root level (defaulting to DEBUG) and specific INFO-level logging for cluster, serialization, and EventStore TCP components. Monitoring is enabled via Kamon with specific filters for Akka actors related to sales systems, eventstore persistence, and saga managers. The service exposes Akka Cluster HTTP Management on port 20000.

headquarters/write-back/src/main/resources, sales/write-back/src/main/resources, sales/write-front/src/main/resources · high confidence

This change introduces the runtime configuration files for the new invoicing write-back service. It defines the Akka cluster settings, including binding to port 9201, joining the cluster via seed nodes, and enabling HTTP management on port 20001. It also sets up logging via Logback with configurable levels (defaulting to INFO) and configures Kamon metrics to monitor specific invoicing-related actors and event store interactions. The eventstore configuration has been moved from the sales-write-back module to this new location.

invoicing/write-back/src/main/resources · high confidence

This change introduces the foundational structure for the ddd-leaven-akka-v2 sample e-commerce application. It adds a Travis CI configuration (.travis.yml) to automate testing with Scala 2.12.6 and Oracle JDK 8, including a local publish step for the monitoring module. The project now includes a MIT LICENSE file, a comprehensive README.md detailing the CQRS/DDD architecture, subsystems (Sales, Invoicing, Shipping, Headquarters), and running instructions, as well as activator.properties for project metadata. Additionally, a restart script for e2e-tests and updated .gitignore rules (excluding .vagrant and /journal) are added to support the development workflow.

(repo-wide) · high confidence

The sales write-back subsystem now includes its application entry point, which automatically joins the Akka cluster and starts the Reservation aggregate root and command reception logic upon member readiness. This initialization integrates with the updated akka-ddd framework, enabling aggregate root monitoring and logging for the reservation process.

sales/write-back/src/main/scala/ecommerce/sales/app · high confidence

The shipping write-back service now includes its main application entry point and configuration traits. The \ShippingBackendApp\ handles cluster startup, automatically registering the Shipment aggregate root and the Department command receptor once the cluster member is up. The \ShippingBackendConfiguration\ trait defines the actor factories for these components, ensuring the Shipment aggregate uses the new \AggregateRootLogger\ for event logging and that command receptors are backed by \EventstoreSubscriber\ actors.

shipping/write-back/src/main/scala/ecommerce/shipping/app · high confidence

Adds a new stress-testing infrastructure for the ecommerce system, containerizing the wrk benchmarking tool via a dedicated Dockerfile and providing shell scripts (start-test-bench.sh, stress.sh, warmup.sh) to orchestrate tests. The setup includes an nginx reverse proxy configuration that routes sales, invoicing, and shipping traffic to specific backend ports, and Lua-based wrk scripts that generate realistic request payloads (including UUIDs and JSON bodies) for load testing.

commons/stress-test · high confidence

The invoicing write-front now exposes an HTTP endpoint to receive commands. A new HttpService actor binds to a configurable interface and port (defined in the 'http-service' config section) and routes requests under the path '/ecommerce/invoicing' to the invoicing command handler. The application entry point starts a supervisor that manages this HTTP service and terminates the system if the service fails.

invoicing/write-front/src/main/scala · high confidence

A new HTTP service has been added to the shipping read-front module, exposing shipping shipment view data via an Akka HTTP endpoint. The service binds to a configurable interface and port, listens at the path prefix 'ecommerce/shipping', and serves requests by querying a PostgreSQL-backed SQL view store. Configuration for the HTTP interface, port, and ask timeout is now managed through the application config under 'app.http-service'.

shipping/read-front/src/main/scala/ecommerce/shipping · high confidence

This change introduces the Headquarters application module, providing a new service for managing the Ordering Process via the OrderProcessManager. It integrates Akka Cluster HTTP Management for operational visibility and configures the system to connect to external offices (Invoicing, Reservation, Shipping) using command queues. The implementation also adds a ClusterView actor to track cluster member status and utilizes the updated akka-ddd framework features, including the OfficeRegistry and AggregateRootLogger.

headquarters/write-back/src/main/scala/ecommerce/headquarters/app · high confidence

The invoicing subsystem now includes a dedicated backend application entry point and configuration trait. The new InvoicingBackendApp initializes the Akka cluster, registers the Invoice aggregate root, and sets up command reception for the Department. The accompanying InvoicingBackendConfiguration defines the actor factory for Invoice aggregates, enabling event logging via AggregateRootLogger, and configures the command receptor to subscribe to the event store.

invoicing/write-back/src/main/scala/ecommerce/invoicing/app · high confidence

Added the core domain contracts for the invoicing subsystem, defining the command and event models for invoice lifecycle management. The new invoice.scala file specifies commands for creating, receiving payment for, and canceling invoices, alongside corresponding events such as InvoiceCreated, OrderBilled, OrderBillingFailed, and PaymentExpired. The package.scala file establishes the invoicing department identifier and configures the command routing to use a remote office queue named 'Invoice', ensuring commands are dispatched to the appropriate external office for processing.

invoicing/contracts/src/main/scala · high confidence

The shipping subsystem now maintains a dedicated read-optimized view of shipment data, enabling efficient queries for shipment status by ID or order ID. This is implemented via a new Slick-based DAO layer that persists \ShipmentView\ records (containing ID, order ID, and status) into a \shippings\ database table, alongside a projection that automatically updates this view whenever a \ShipmentCreated\ event occurs.

shipping/read-back/src/main/scala/ecommerce/shipping/view · high confidence

The sales read-front module is introduced, providing an HTTP service (defaulting to port 9110) that exposes reservation data via REST endpoints. Users can retrieve all reservations through GET /reservation/all or fetch a specific reservation by ID via GET /reservation/{id}, which returns a 404 status if the reservation is not found. The service is configured via application.conf and logback.xml, supporting environment variable overrides for host and port, and integrates with a SQL view store backed by Slick and PostgreSQL.

sales/read-front · high confidence

The system now includes an Invoice aggregate that manages the lifecycle of an invoice from creation to payment or cancellation. Users can create an invoice with order and customer details, receive payments which update the paid amount, or cancel the invoice, which triggers a billing failure event. This aggregate is built on the akka-ddd framework and integrates with the local office context.

invoicing/write-back/src/main/scala/ecommerce/invoicing · high confidence

A new Shipment aggregate has been added to the shipping write-back module, defining the core domain model for shipment lifecycle management. It implements an aggregate root with two states: Uninitialized and Active. The Uninitialized state handles the CreateShipment command, validating that the shipment does not already exist before emitting a ShipmentCreated event, which transitions the aggregate to the Active state. The Active state currently has no further actions defined. The aggregate is configured with a LocalOfficeId derived from a ShippingOfficeId, integrating it into the existing office-based architecture.

shipping/write-back/src/main/scala/ecommerce/shipping · high confidence

Added Vagrant configuration files and shell scripts to virtualize the entire system for end-to-end testing. The setup provisions an Ubuntu VM running Docker, which orchestrates containers for the EventStore, a PostgreSQL view store, and the application subsystems (headquarters, sales, invoicing, shipping). This enables developers to spin up, restart, or destroy the complete distributed environment using simple commands like \vagrant up\ or \./destroy-all\.

e2e-tests · high confidence

A new ReservationAggregateRoot has been added to the sales write-back module, defining the core state machine for managing product reservations. This component enables users to create reservations, reserve specific products (updating quantities or adding new items), confirm the reservation to calculate the total amount, and subsequently cancel or close the reservation. The aggregate handles transitions between uninitialized, open, confirmed, canceled, and closed states, ensuring that once a reservation is canceled or closed, no further modifications are allowed.

sales/write-back/src/main/scala/ecommerce/sales · high confidence

A new Main.scala entry point has been added to the commons module to bootstrap the Akka system. This component loads configuration, creates a classloader for deployable JARs, and executes startup/shutdown hooks for specified boot classes (including a monitoring runner). This provides the foundational startup logic for the application, replacing or supplementing previous manual initialization methods.

commons/src · high confidence

Introduces the OrderProcessManager, a new saga that orchestrates the complete order lifecycle from reservation confirmation through payment, billing, and shipment. The process automatically creates an invoice upon reservation confirmation, handles payment expiration or billing failures by cancelling invoices or reservations, and transitions to delivery by closing the reservation and creating a shipment once billing succeeds. This centralizes the coordination between sales, invoicing, and shipping domains within the headquarters write-back service.

headquarters/write-back/src/main/scala/ecommerce/headquarters/processes · high confidence

The shipping read-front now exposes HTTP endpoints to retrieve shipment data, including a list of all shipments, a specific shipment by ID, and shipments linked to a specific order ID. This functionality is implemented in the new ShipmentViewEndpoint class, which queries the underlying database via the ShipmentDao and SqlViewStore, returning appropriate HTTP responses including 404 Not Found for missing resources. The application entry point, ShippingReadFrontApp, has been updated to initialize the HTTP service using the configured interface, port, and timeout settings.

shipping/read-front/src/main/scala/ecommerce/shipping/app · high confidence

A new ShippingViewUpdateService has been introduced in the shipping read-back module to manage reactive view updates using a Slick-based SQL view store. This service initializes the 'shipping-shipments' view by configuring a ShipmentProjection and ensures the underlying database schema is created upon startup, replacing previous initialization logic with a dedicated service class that extends SqlViewUpdateService.

shipping/read-back/src/main/scala/ecommerce/shipping · high confidence

This change introduces a set of shell scripts and configuration files to simplify running the application locally. The \commons/run-scripts\ directory now contains an \environment\ file that sets the Akka cluster seed and host, along with individual launch scripts for each service component (headquarters, invoicing, sales, and shipping) and a \run-all\ script to start them all in the background. A \stop-all\ script is also provided to terminate running Akka nodes. Additionally, \commons/supervisord-configs\ adds \.conf\ files for the invoicing, sales, and shipping modules, defining how each service should be managed by supervisord, including JVM memory settings and class paths.

commons/run-scripts · high confidence

The sales read-back module now includes a dedicated service for updating the sales reservations view. This service configures the projection for sales reservations and ensures the underlying database schema is created when the view update process starts, preventing errors during initialization.

sales/read-back/src/main/scala/ecommerce/sales · high confidence

The legacy HTTP service implementation for the sales-write-front module has been removed. This change deletes the \BaseApp\ entry point and the \HttpService\ actor, which previously exposed an Akka HTTP endpoint at \/ecommerce/sales\ to handle sales commands via JSON marshalling. Users of this specific front-end service will no longer have access to this HTTP interface, indicating a shift away from this Akka-based implementation.

sales-write-front/src/main/scala · high confidence

The sales-write-back module has removed the core Reservation aggregate implementation, the EventStoreSerializer, and the associated Akka serialization configuration. This deletes the code responsible for handling reservation creation, product reservation, confirmation, and closure, along with the specific JSON serialization bindings for reservation-related events. The application entry point (SalesBackendApp) that wired these components into the Akka cluster is also removed, effectively eliminating this specific sales write-back capability from the system.

sales-write-back/src/main · high confidence

A new configuration file (tags.conf) has been added to define the 'order' tag, associating it with specific ecommerce events including ReservationConfirmed, OrderBilled, OrderBillingFailed, and PaymentExpired. This enables the system to categorize and process these specific order-related events under a unified tag.

headquarters/event-tagging · high confidence

New shell scripts in the commons directory (\create-projection\ and \create-projections\) were added to simplify the deployment of Event Store continuous projections. The \create-projection\ script provides a reusable interface for creating individual projections via HTTP, while \create-projections\ uses this helper to automatically enable standard projections such as \clock\_proj\, \current\_deadlines\_proj\, and \tags\_proj\ by pointing to their respective JavaScript definitions in the headquarters module.

commons · high confidence

The build system has been upgraded from SBT 0.13.7 to 1.1.6, requiring a migration of the build definition. The project structure has been refactored into modular SBT plugins (ApplicationPlugin, HttpServerPlugin, MonitoringPlugin, etc.) to better organize settings for different subsystems. Dependency management has been updated to use Akka 2.5.13, Akka-DDD 1.7.9-SNAPSHOT, and Kamon 0.6.6, while replacing older plugins like sbt-multi-jvm with sbt-coursier for dependency resolution. Docker packaging is now handled by sbt-native-packager 1.2.2, and end-to-end testing is supported via a new Vagrant integration.

project · high confidence

The read-front service now includes explicit configuration for its HTTP interface (defaulting to 0.0.0.0:9310 with environment variable overrides) and logging behavior. Logging is set to DEBUG by default but can be overridden at runtime via the ECOMMERCE\_LOG\_LEVEL environment variable, with specific adjustments to reduce noise from Slick database operations to INFO level.

shipping/read-front/src/main/resources · high confidence

The read-back service now includes dedicated configuration files for Akka logging and Event Store connectivity. Logging is now driven by Logback with a pattern that includes Akka timestamps and source information, and the root log level is configurable at runtime via the ECOMMERCE\_LOG\_LEVEL environment variable (defaulting to DEBUG). Additionally, the service connects to an Event Store instance (defaulting to localhost:1113) with credentials that can be overridden by environment variables (ES\_HOST, ES\_LOGIN, ES\_PASSWORD).

sales/read-back/src/main/resources · high confidence

The sales and shipping contract modules now include reference configuration files that register their respective serialization hints providers (SalesSerializationHintsProvider and ShippingSerializationHintsProvider) and disable the Akka warning about Java serializer usage. This ensures that serialization hints are explicitly applied for these domains and prevents runtime warnings related to Java serialization.

sales/contracts/src/main/resources, shipping/contracts/src/main/resources · high confidence

The system no longer logs warnings when Java serialization is used for actor messages. This change suppresses the \akka.actor.warn-about-java-serializer-usage\ warning in the reference configuration, reducing log noise for existing serialization patterns.

invoicing/contracts/src/main/resources · high confidence

The application now uses a dedicated logback configuration that suppresses verbose Akka remoting and cluster heartbeat logs while allowing the root log level to be configured at runtime via the ECOMMERCE\_LOG\_LEVEL environment variable. The service's HTTP interface has moved from 127.0.0.1:9100 to 0.0.0.0:9200, and the backend contact point has been updated to point to the 'ecommerce' system on port 9201. Additionally, the ask-timeout for service calls was increased from 3 to 10 seconds, and Akka cluster extensions were updated to use the ClusterClientReceptionist.

invoicing/write-front/src/main/resources · high confidence

The sales write-front service has been updated to use Akka HTTP 1.0 and Akka 2.4.2-RC2, requiring adjustments to the HTTP service implementation and startup logic. The application now uses the Akka \Bootable\ interface for initialization instead of the previous \BaseApp\ pattern, and the HTTP service explicitly binds to a configurable interface and port while exposing a default health check route. Additionally, the internal configuration trait was refactored to remove the \GlobalOfficeClientSupport\ dependency and renamed the \askTimeout\ setting to \timeout\ to align with the updated Akka DDD library version 1.7.0.

sales/write-front/src/main/scala · high confidence

The \package.scala\ file in the \sales-contracts\ module, which previously defined JSON serialization settings (including stream names and type hints for reservation commands, events, and value objects), has been deleted. This change removes the local serialization configuration for the sales contracts module, likely shifting this responsibility to a different part of the system or a shared configuration layer.

sales-contracts · medium confidence

The sales contracts module has been reorganized and its domain model updated to align with framework changes. The package structure was moved from \sales-contracts\ to \sales/contracts\, introducing a new \SalesSerializationHintsProvider\ that uses \EnumNameSerializer\ for \ProductType\ and defines a \ReservationOfficeId\ for external command queues. The \reservation.scala\ file now uses a specific \ReservationId\ type instead of the generic \EntityId\, renames \clientId\ to \customerId\ in commands and events, introduces a \CancelReservation\ command and corresponding \ReservationCanceled\ event, and adds a \Canceled\ status to \ReservationStatus\. Additionally, the \Product\ model was simplified by removing the \AggregateSnapshotId\ wrapper in favor of direct \id\ and \version\ fields, and \Money\ now has a default zero-argument constructor.

sales/contracts/src/main/scala · high confidence

The shipping contracts module now defines its core domain model, including the \ShippingStatus\ enumeration (Waiting, Sent, Delivered) and command/event types like \CreateShipment\, \ShipmentCreated\, and \GoodsDelivered\. It introduces \ShipmentId\ as an \AggregateId\ and configures \ShippingOfficeId\ for remote office communication. Serialization is handled by \ShippingSerializationHintsProvider\, which uses \EnumNameSerializer\ for \ShippingStatus\ instead of the previous \EnumSerializer\, ensuring consistent JSON representation of status values.

shipping/contracts/src/main/scala · high confidence

The shipping/write-back module now includes dedicated configuration for connecting to an Event Store (with environment-variable overrides for host and credentials) and integrates Akka Cluster HTTP Management on port 20002. The service's default HTTP port changed from 2551 to 9301, and it now auto-joins the cluster using the configured seed node. Logging is standardized via a new logback.xml that writes to the console with Akka-specific formatting, and the root log level is controlled by the ECOMMERCE\_LOG\_LEVEL environment variable (defaulting to INFO). The application switched from the ClusterReceptionist to the ClusterClientReceptionist extension, and removed the now-unnecessary serialization include.

shipping/write-back/src/main/resources · high confidence

Added e2e test infrastructure with REST-assured integration; Added end-to-end system test for the ecommerce workflow; Added test configuration files for Akka persistence; Added test configuration for H2 database and logging; Added tests for Order Process Manager behavior; Added tests for ReservationProjection; Added tests for ShipmentProjection; Added tests for ShipmentViewEndpoint; Removed redundant test support configuration files; Updated ReservationSpec tests to align with akka-ddd 1.7.0 API changes.

The build system has been upgraded from Scala 2.11.4 to 2.12.6, requiring compatibility updates across all modules. The project structure has been refactored from a flat list of subprojects (e.g., \sales-contracts\, \sales-write-back\) into a hierarchical model organized by business subsystems (\sales\, \invoicing\, \shipping\, \headquarters\, \commons\, \monitoring\, \e2e-tests\). This change introduces new \build.sbt\ files for each subsystem, consolidating dependencies like Akka-DDD, Kamon, and Docker packaging settings, and adds sbt command aliases (\redeploy\, \redeployQuick\) to streamline development and deployment workflows.

(dependencies) · high confidence

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

• CAI 46 → 42 (-3.8)
• Rubric changed (rubric-2026.08.17 → rubric-2026.09.15) — scores are not directly comparable.

• Code Health 100 → 99 (-0.8)
• Architecture 82 → 98 (+16.9)
• Maturity 48 → 51 (+3.0)
• Readiness 46 → 34 (-11.7)
• Security 94 → 97 (+3.0)
• Domain Modelling 84 → 72 (-12.1)
• Event Sourcing 43 → 43 (+0.0)
• Accessibility 40 → 40 (+0.0)

• Boundary-crossing change coupling: Deps.scala ↔ HttpService.scala (project/Deps.scala)
• Boundary-crossing change coupling: Deps.scala ↔ ReservationViewEndpoint.scala (project/Deps.scala)
• Boundary-crossing change coupling: HeadquartersConfiguration.scala ↔ InvoicingBackendConfiguration.scala (headquarters/write-back/src/main/scala/ecommerce/headquarters/app/HeadquartersConfiguration.scala)
• Boundary-crossing change coupling: HeadquartersConfiguration.scala ↔ SalesBackendConfiguration.scala (headquarters/write-back/src/main/scala/ecommerce/headquarters/app/HeadquartersConfiguration.scala)
• Boundary-crossing change coupling: HeadquartersConfiguration.scala ↔ ShippingBackendConfiguration.scala (headquarters/write-back/src/main/scala/ecommerce/headquarters/app/HeadquartersConfiguration.scala)
• Boundary-crossing change coupling: HttpService.scala ↔ ShipmentViewEndpoint.scala (sales/read-front/src/main/scala/ecommerce/sales/HttpService.scala)
• Boundary-crossing change coupling: InvoicingBackendConfiguration.scala ↔ ShippingBackendConfiguration.scala (invoicing/write-back/src/main/scala/ecommerce/invoicing/app/InvoicingBackendConfiguration.scala)
• Boundary-crossing change coupling: SalesBackendConfiguration.scala ↔ ShippingBackendConfiguration.scala (sales/write-back/src/main/scala/ecommerce/sales/app/SalesBackendConfiguration.scala)
• Boundary-crossing change coupling: SalesViewUpdateService.scala ↔ ShippingViewUpdateService.scala (sales/read-back/src/main/scala/ecommerce/sales/SalesViewUpdateService.scala)
• Coverage not included — suite not readable by the collector
• Dependency hygiene not measured — no supported dependency manifest was read
• High IaC: DS-0002 (commons/stress-test/Dockerfile)
• High IaC: DS-0029 (commons/stress-test/Dockerfile)
• Low IaC: DS-0026 (commons/stress-test/Dockerfile)
• Low: security finding (details withheld)
• Low: security finding (details withheld)
• Low: security finding (details withheld)
• Low: security finding (details withheld)
• Low: security finding (details withheld)
• Low: security finding (details withheld)
• …and 5 more

• Documentation: no installation or build instructions (README.md)
• Documentation: no usage examples (README.md)
• Duplicated block (16–17 lines × 2) (sales/read-front/src/main/scala/ecommerce/sales/app/ReservationViewEndpoint.scala)
• Low: security finding (details withheld)
• Low: security finding (details withheld)
• Low: security finding (details withheld)
• Low: security finding (details withheld)
• Low: security finding (details withheld)
• Low: security finding (details withheld)
• TodoComment (headquarters/write-back/src/main/scala/ecommerce/headquarters/app/HeadquartersConfiguration.scala)
• TodoComment (sales/read-back/src/main/scala/ecommerce/sales/view/ReservationProjection.scala)

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

pawelkaczor/ddd-leaven-akka-v2 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.