denis.sajnar/cqrs-microservices

This system is a CQRS-based microservice architecture for order management, split into a command service for writing order data and a query service for reading it. The command service exposes a REST API to create, update, and delete orders, persisting events to MongoDB via an outbox pattern for reliable dispatch to RabbitMQ. The query service consumes these events to maintain a PostgreSQL-backed read model, exposing a versioned API for order retrieval.

The architecture module now includes automated tests using Konsist to enforce strict hexagonal layering rules, ensuring that domain, port, use-case, and adapter layers do not violate their intended dependencies. Additionally, the observability module introduces a CorrelationIdFilter that injects a unique ID into request logs via MDC, improving traceability across services, and an HttpExchangeLoggingFilter that logs HTTP exchanges with sensitive data redaction.

(repo-wide) · high confidence

This change introduces the foundational structure for the CQRS microservices project, including the hexagonal architecture modules, domain context definitions, and a Docker Compose stack for local development (MongoDB, PostgreSQL, RabbitMQ). It establishes the build system with Gradle 9.7.1, Java 25 toolchain provisioning, and strict dependency locking via \gradle.lockfile\ to ensure reproducible builds and security scanning. The entry also adds CI/CD configuration for GitLab, enforcing Conventional Commits, code quality gates (ktlint, detekt), and security scans (Trivy, Semgrep), while configuring Scalar for API reference documentation and defining the API versioning strategy via headers.

(repo-wide) · high confidence

The order-command-service core module now contains the foundational domain model and application use cases for the order write side. This includes the \OrderAggregate\ which manages order state and enforces invariants (such as preventing updates to shipped orders), command objects (\CreateOrderCommand\, \UpdateOrderCommand\, \DeleteOrderCommand\) with validation logic, and error types like \ConcurrentModification\ and \OrderInvariantViolated\. The module also introduces the \UseCase\ annotation to mark application services, implements the \Orders\ and \OrderHistory\ use case interfaces, and adds a new \OutboxDispatch\ use case to handle reliable event publication via an outbox pattern. Additionally, it defines a unified \Page\ and \Pagination\ vocabulary for consistent result set handling across the service.

order-command-service/core · high confidence

Added three new scripts to the repository: \check-deprecations.py\ validates application configuration against the pinned Spring Boot version to fail the build on deprecated properties; \coverage-summary.sh\ parses JaCoCo XML reports to output a standardized coverage line for GitLab; and \setup-hooks.sh\ configures local Git to use the \.githooks\ directory for pre-commit validation.

scripts · high confidence

The order command service now exposes a REST API for creating, updating, and deleting orders, alongside monitoring endpoints for the event log and outbox. The API uses SpringDoc OpenAPI for documentation and enforces validation on request bodies. Internally, the service persists order events and outbox records in MongoDB, utilizing unique compound indexes to guarantee version consistency and atomic outbox claiming for reliable event dispatch.

(repo-wide) · high confidence

The order command service now implements an outbox pattern to ensure reliable event delivery, with a scheduled dispatcher that purges records after seven days and configuration for RabbitMQ publisher confirms and returns. API versioning has moved from the URL path to the X-API-Version header, with version 1 as the default and unsupported versions rejected with a 400 error. The service includes integration tests covering the outbox atomicity, event log uniqueness, error contracts using RFC 9457 problem details, and API versioning behavior, along with test containers for MongoDB and RabbitMQ.

order-command-service/app/src · high confidence

The order-query-service is introduced as a new Spring Boot application that maintains a PostgreSQL-backed read model by consuming events from RabbitMQ. It features an inbox mechanism for idempotent event processing, automatic projection scheduling, and dead-letter queue handling for unprocessable messages. The API is versioned via the X-API-Version header, and the service exposes a Scalar-based API reference at /docs. The service is configured to run with virtual threads and integrates with Docker Compose for local development infrastructure.

order-query-service/app · high confidence

The web module now identifies its API version via the X-API-Version header instead of the URL path, allowing clients to use the same endpoints across versions. Additionally, error handling has been unified into a single ProblemDetailHandler that returns RFC 9457 compliant JSON for all validation and internal errors, ensuring consistent error shapes across both read and write services.

web · high confidence

The repository now includes local Git hooks to improve code quality before pushing. The commit-msg hook enforces Conventional Commit formatting on the commit subject, requiring a type (such as feat, fix, or refactor) and an optional scope. The pre-push hook automatically runs Kotlin linting and static analysis (lintKotlin and detekt) via Gradle whenever Kotlin files are changed in the push, while skipping the check if no Kotlin code is modified or if the working tree is dirty.

.githooks · high confidence

The build-logic module now enforces reproducible builds via new Gradle dependency lockfiles and introduces a DockerLock service to serialize Testcontainers usage, preventing race conditions and worker crashes during parallel test execution. Additionally, the conventions enforce strict Java deprecation and removal warnings, align Kotlin analyzer versions to avoid compiler mismatches, and apply security patches for Tomcat and RabbitMQ to ensure the pipeline fails on critical vulnerabilities.

build-logic · high confidence

The order-command-service adapters now use Gradle dependency locking to ensure reproducible builds. New lockfiles have been added for the REST input adapter, the MongoDB output adapter, and the RabbitMQ output adapter, pinning specific versions for all compile, runtime, and test dependencies in those modules.

order-command-service/adapter · high confidence

The build system now enforces deterministic dependency resolution for the order-query-service adapters by adding Gradle dependency lockfiles for the RabbitMQ input, REST input, and PostgreSQL output modules. This ensures that all transitive dependencies (including Spring Boot 4.1.1, Kotlin 2.4.20, and Hibernate 7.4.5) are pinned to specific versions, preventing unexpected changes in the runtime environment.

order-query-service/adapter · high confidence

The project now uses Gradle 9.7.1 for builds, replacing the previous wrapper configuration. This ensures consistent build environments across development and CI by pinning the specific distribution URL and checksum, and includes updated network timeout and retry settings for more reliable downloads.

gradle · high confidence

The project introduces a comprehensive Gradle build structure, including a version catalog (\libs.versions.toml\) that defines dependencies such as Spring Boot 4.1.1, Kotlin 2.4.20, and Jackson 3. The build enforces strict dependency locking via \gradle.lockfile\ to ensure reproducible builds and secure scanning by Trivy, and it configures unique module coordinates to prevent resolution conflicts. Additionally, the setup includes convention plugins in \build-logic\, architecture validation using Konsist, and JaCoCo coverage aggregation across the multi-module services.

(dependencies) · high confidence

The order-command-service now uses Gradle dependency locking to ensure reproducible builds. A new gradle.lockfile has been added to the repository, capturing the exact versions of all production, test, and development dependencies (such as Jackson 2.21.5, Kotlin 2.4.20, and Netty 4.2.17) to prevent unexpected version drift during builds.

order-command-service/app · high confidence

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

• CAI 54 → 72 (+17.1)
• Rubric changed (rubric-2026.08.19 → rubric-2026.09.15) — scores are not directly comparable.

• Code Health 100 → 98 (-2.4)
• Architecture 100 → 77 (-23.5)
• Maturity 60 → 85 (+25.0)
• Readiness 26 → 85 (+59.5)
• Security 100 → 85 (-15.0)
• Domain Modelling 60 (new)

• Coverage not included — suite not readable by the collector
• Dependency hygiene not measured — dependency manifest found but not parsed for hygiene
• No exposed public API
• Test reliability not included
• The overview lists 'Transactional Inbox Pattern' but there is no visible description or run command for it. (README.md)
• The overview mentions 'Transactional Outbox Pattern' but the visible content does not show how to configure or invoke it in code. (README.md)
• early-stage repository — too little history to judge knowledge freshness
• git history depth insufficient
• git history depth insufficient
• single-maintainer — knowledge-concentration (bus factor) risk

• ADR not followed: The outbox is atomic, or it is not an outbox (docs/adr/0005-the-outbox-is-atomic-or-it-is-not-an-outbox.md)
• Dependency hygiene PARTLY measured — Maven/Gradle declarations read, no dependency graph resolved
• Documentation: no installation or build instructions
• Documentation: no usage examples
• Medium CVE: [GHSA redacted] (build-logic/gradle.lockfile)
• Medium IaC: WD-COMPOSE-0002 (compose.yaml)
• Medium IaC: WD-COMPOSE-0002 (compose.yaml)
• Medium IaC: WD-COMPOSE-0002 (compose.yaml)
• No SBOM
• No artifact signing
• No build provenance
• check-deprecations.load_deprecations (cognitive 38) (scripts/check-deprecations.py)
• check-deprecations.main (cognitive 41) (scripts/check-deprecations.py)
• check-deprecations.main (cyclomatic 21) (scripts/check-deprecations.py)

• 48 commits — 43 feature/other, 5 fixes

• (repo) — 24 commits
• (root) — 7 commits
• order-command-service/core — 4 commits
• order-command-service/adapter — 2 commits
• order-command-service/src — 2 commits
• order-query-service/adapter — 2 commits
• order-query-service/app — 2 commits
• architecture/src — 1 commit
• docs/adr — 1 commit
• docs/agents — 1 commit
• observability/src — 1 commit
• order-command-service/app — 1 commit

• fix: Merge branch 'fix/bootrun-finds-the-compose-file' into 'master'
• fix: Merge branch 'fix/logging-to-the-wellplanned-standard' into 'master'
• fix: fix(app): let bootRun find the compose file, and leave the stack up behind it
• fix: fix(observability): allow-list the headers, and let the outcome pick the summary's level
• fix: fix: give every module a unique coordinate, and land the defects behind it
• change: Configure agent skills for GitLab issues and domain docs
• change: Make the code say what the domain means
• change: Merge branch 'build/assert-every-resolving-project-has-a-lockfile' into 'master'
• change: Merge branch 'chore/unify-look-and-feel-with-task-management' into 'master'
• change: Merge branch 'ci/gate-every-deprecation-not-just-config' into 'master'
• change: Merge branch 'docs/agent-skills-config' into 'master'
• change: Merge branch 'docs/conventional-commits-badge' into 'master'
• change: Merge branch 'docs/correct-what-the-page-flags-replaced' into 'master'
• change: Merge branch 'docs/readme-after-the-versioning-change' into 'master'
• change: Merge branch 'docs/readme-unification' into 'master'
• change: Merge branch 'feat/api-version-in-a-header' into 'master'
• change: Merge branch 'feat/scalar-reference-and-rolling-changelog' into 'master'
• change: Merge branch 'refactor/a-clock-and-published-fakes' into 'master'
• change: Merge branch 'refactor/hexagonal-architecture-and-toolchain' into 'master'
• change: Merge branch 'refactor/name-the-scheduler-and-gate-the-hexagon' into 'master'
• …and 28 more

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

denis.sajnar/cqrs-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.