SpringBootCourses/cqrs-banking-app

This system is a financial management platform built on a microservices architecture, separating a synchronous REST API from an asynchronous event-driven processing layer. The core-service exposes a REST API for managing clients, cards, and transactions, while the event-handler processes Kafka streams to persist financial entities. The infrastructure supports local development with PostgreSQL, Kafka, and Debezium for change data capture.

The application now provides a complete local development environment via Docker Compose, defining services for the Java backend (port 8080) and an event handler (port 8081). The configuration also provisions a PostgreSQL database with logical replication enabled, a Zookeeper and Kafka cluster for event streaming, and a Debezium Connect instance for change data capture. Environment variables for database credentials, JWT secrets, and Kafka/Debezium settings are managed through a new .env.example file.

(repo-wide) · high confidence

A new configuration file (conf/postgres-connector.json) and a helper script (conf/run.sh) have been added to set up a Debezium PostgreSQL connector. The configuration defines a Kafka Connect source connector that streams the 'public.events' table from a local PostgreSQL instance to Kafka, using the pgoutput plugin and applying transformations to unwrap and route the data.

conf · high confidence

Added new domain models for Account, Card, Client, and Transaction, along with their corresponding Spring Data JPA repositories. The change also introduces a generic QueryService interface and specific implementations for each entity, enabling standardized read operations across the application's core business entities.

common · high confidence

The core-service now exposes a REST API for managing clients, cards, and transactions. Users can register and log in via the /api/v1/auth endpoints, which issue JWT access and refresh tokens. The /api/v1/clients endpoints allow retrieving client details, their associated cards, and account information. Card creation and retrieval are available at /api/v1/cards, including fetching transactions for a specific card. Transaction creation and retrieval are handled at /api/v1/transactions. The service implements a layered architecture with controllers, services, and mappers, and includes global exception handling for validation, authentication, and access denial errors.

core-service · high confidence

The event-handler module now implements a Kafka-based event processing system that listens for create events for Accounts, Cards, Clients, and Transactions. Each event is routed to a dedicated handler (e.g., AccountCreateEventHandler) which deserializes the payload using Gson and persists the entity via a corresponding service (e.g., AccountService). The system includes configuration for JSON deserialization of LocalDateTime and manual Kafka acknowledgment.

event-handler · high confidence

The project is initialized with a Maven multi-module structure, defining parent and child POMs for 'common', 'core-service', and 'event-handler' modules. This establishes the build configuration for the application, including dependencies for Spring Boot 3.2.5, PostgreSQL 42.7.3, Liquibase 4.27.0, Lombok 1.18.32, and Spring Kafka 3.1.4.

(dependencies) · high confidence

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

• CAI 52 → 48 (-4.3)
• Rubric changed (rubric-2026.08.19 → rubric-2026.09.15) — scores are not directly comparable.

• Code Health 100 → 100 (+0.0)
• Architecture 57 (new)
• Maturity 43 → 43 (+0.0)
• Readiness 44 → 37 (-7.0)
• Security 80 → 84 (+3.7)
• Domain Modelling 70 → 79 (+9.0)

• Dependency hygiene not measured — dependency manifest found but not parsed for hygiene
• High: security finding (details withheld)
• High: security finding (details withheld)
• High: security finding (details withheld)
• Medium IaC: CKV_DOCKER_3 (core.Dockerfile)
• Medium IaC: CKV_DOCKER_3 (event-handler.Dockerfile)
• No exposed public API
• Scanner failed to run — not a clean result
• The README links to a Google Docs document explaining the pattern but never states where that document lives or how to access it. (README.md)
• change coupling unreadable for .java — no production change history could be paired for this repository's own source
• dormant codebase — no living knowledge left to concentrate

• Dependency hygiene PARTLY measured — Maven/Gradle declarations read, no dependency graph resolved
• Documentation: no installation or build instructions (README.md)
• High IaC: WD-COMPOSE-0002 (compose.yaml)
• High IaC: WD-COMPOSE-0002 (compose.yaml)
• High: security finding (details withheld)
• High: security finding (details withheld)
• High: security finding (details withheld)
• Medium IaC: WD-COMPOSE-0002 (compose.yaml)
• Medium IaC: WD-COMPOSE-0002 (compose.yaml)
• Medium IaC: WD-DOCKER-0003 (core.Dockerfile)
• Medium IaC: WD-DOCKER-0003 (core.Dockerfile)
• Medium IaC: WD-DOCKER-0003 (event-handler.Dockerfile)
• Medium IaC: WD-DOCKER-0003 (event-handler.Dockerfile)
• Medium: security finding (details withheld)
• Medium: security finding (details withheld)
• Medium: security finding (details withheld)
• No ADRs found
• Scanner failed to run — not a clean result
• Scanner failed to run — not a clean result
• Workflow token permissions not restricted

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

SpringBootCourses/cqrs-banking-app 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.