valentinajemuovic/banking-kata-java

This system is a Java-based banking application built on Clean Architecture principles, designed to manage bank accounts through operations like opening, depositing, and withdrawing funds. It abstracts external dependencies via pluggable adapters, supporting multiple persistence backends (JPA, MongoDB, Redis), messaging systems (RabbitMQ, in-memory), and third-party integrations for identity and customer verification. The codebase emphasizes testability by providing comprehensive fake implementations for all external services, enabling deterministic unit and contract testing across the domain logic.

20 changes.

The project was initialized as a Java-based Banking Kata, establishing a multi-module Gradle structure based on Clean Architecture principles. Core domain logic, use cases, and persistence adapters were implemented alongside comprehensive test fixtures and infrastructure configuration for local development.

24 changes.

This period focused on implementing a comprehensive set of pluggable adapters for persistence, messaging, and external integrations, alongside their corresponding fake and real variants. Significant effort was dedicated to establishing a robust testing framework, including contract tests, in-memory storage, and deterministic service fakes to support the new microservice architecture.

This change introduces a new JPA-driven persistence layer for bank accounts within the \adapter-persistence-jpa\ module. It includes a \BankAccountRecord\ entity mapped to a \bank\account\ table, a Spring Data \CrudRepository\ interface for data access, and a \JpaBankAccountStorage\ component that implements the \BankAccountStorage\ port. The storage implementation handles finding, adding, and updating bank accounts, utilizing MapStruct for DTO-to-entity mapping. A Flyway migration script (\V1\\_Schema\_Jpa.sql\) is provided to create the underlying database schema, and the storage bean is marked as \@Primary\ and activated via the \ADAPTER\_PERSISTENCE\_JPA\ profile.

adapter-persistence-jdbc, adapter-persistence-jpa/src/main, adapter-persistence-redis · high confidence

The application now supports RabbitMQ as a messaging backend for the event bus. This change introduces a new \RabbitMQEventBus\ implementation that publishes domain events to a configurable exchange and queue, along with the necessary Spring configuration (\RabbitMQConfig\) to establish the connection, define default durable exchanges/queues/bindings, and handle JSON serialization. An \AdminAMQP\ component is also added to allow programmatic management of exchanges and queues, and the adapter is activated via the \ADAPTER\_MESSAGING\_RABBITMQ\ profile.

adapter-messaging-rabbitmq · high confidence

The adapter-time-system module now includes a SysDateTimeService that implements the DateTimeService port to return the current system date and time. This component is registered as a Spring bean and is active only when the 'adapter-time-system' profile is enabled, providing a concrete implementation for retrieving the current timestamp in the banking application.

adapter-time-system · high confidence

A new FacadeFactory class has been introduced in the test-facade module to streamline the creation of the Facade for testing purposes. This factory instantiates and configures all necessary fake adapters—including FakeNationalIdentityGateway, FakeCustomerGateway, FakeAccountIdGenerator, FakeAccountNumberGenerator, FakeDateTimeService, FakeBankAccountStorage, and FakeEventBus—with predefined test data, allowing tests to obtain a fully wired Facade instance with a single method call.

test-facade · high confidence

A new FakeEventBus implementation has been added to the adapter-messaging-fake module to support testing. This class implements the EventBus interface, storing published events in a queue and providing a shouldHavePublishedExactly assertion method to verify that specific events were published. A corresponding test class extends the base EventBusTest to validate this fake implementation.

adapter-messaging-fake · high confidence

New helper classes (HttpHost, HttpMethodName, HttpStatusValue) were added to the test-fixtures module to provide static constants for common HTTP values (localhost, GET method, 200/404 status codes). These utilities standardize HTTP references in contract tests, reducing duplication and ensuring consistent values across test scenarios.

test-fixtures/src/main/java/com/optivem/kata/banking/core/common/http · high confidence

New environment files (.env.local, env.sh, env.ps1, env.intellij.ui) have been added to the env directory to configure local development dependencies. These files define connection details and credentials for PostgreSQL, MongoDB, Keycloak, Redis, and RabbitMQ, enabling developers to run the required infrastructure services locally.

env · high confidence

The adapter-time-fake module now includes a FakeDateTimeService that implements the DateTimeService port, allowing tests to inject specific date-time values via setupNow() and retrieve them via now(). A custom exception (NextDateTimeIsNotConfiguredException) is thrown if now() is called without a configured value. Unit tests verify the service correctly returns the configured date-time.

adapter-time-fake · high confidence

The adapter layer now includes \FakeAccountIdGenerator\ and \FakeAccountNumberGenerator\, which implement the \AccountIdGenerator\ and \AccountNumberGenerator\ ports respectively. These classes extend a new internal \FakeGenerator\ base that allows tests to pre-configure specific return values via a \setupNext\ method, enabling deterministic testing of banking logic that depends on generated identifiers.

adapter-generation-fake/src/main · high confidence

The adapter-thirdparty-fake module now includes a fake implementation of the NationalIdentityGateway, allowing the system to simulate national identity verification during testing. This includes a core fake provider that tracks identity numbers in memory, a Spring component that activates this provider under the 'adapter-thirdparty-sim' profile with pre-configured test identities, and corresponding contract tests to verify the adapter's behavior.

adapter-thirdparty-fake · high confidence

The adapter-persistence-fake module now includes a new FakeBankAccountStorage implementation that provides an in-memory, map-backed store for bank accounts. This adapter implements the BankAccountStorage port and ensures data integrity by returning cloned copies of BankAccountDto objects on retrieval, preventing external mutation of stored state. It also enforces repository constraints by throwing exceptions when attempting to add duplicate account numbers or update non-existent accounts. Comprehensive test coverage is provided via FakeBankAccountStorageTest and FakeBankAccountStorageExtendedTest, verifying correct add, find, update, and constraint-violation behaviors.

adapter-persistence-fake · high confidence

The adapter-messaging-inmemory module now includes a new in-memory implementation of the EventBus interface. This change introduces ApplicationEventBus, which delegates event publishing to Spring's ApplicationEventPublisher, supported by internal components DomainApplicationEvent, EventQueue, and UseCaseEventHandler to manage event lifecycle and queuing within the application context.

adapter-messaging-inmemory · high confidence

This change introduces two new adapter components for generating random identifiers: \RandomAccountIdGenerator\, which uses a Snowflake ID algorithm to produce unique account IDs, and \RandomAccountNumberGenerator\, which utilizes ULID to generate account numbers. Both components are registered as Spring beans and are activated only when the \ADAPTER\_GENERATION\_RANDOM\ profile is active. Corresponding unit tests have been added to verify the instantiation and basic functionality of these generators.

adapter-generation-random · high confidence

The adapter-thirdparty-real module now includes a concrete implementation of the NationalIdentityGateway that calls an external HTTP service to verify user existence via national identity number. This new RealNationalIdentityGateway component uses Spring WebFlux WebClient to query a remote endpoint, returning true if a user record is found and false otherwise. The change also introduces corresponding contract tests using Pact to verify the integration behavior with the national identity provider, ensuring the adapter correctly handles both existing and non-existing user scenarios.

adapter-thirdparty-real · high confidence

This change introduces the implementation layer for the banking core's clean architecture, specifically within the ACL (Adapter) package. It adds converters to map domain entities (BankAccount, AccountOpened, FundsDeposited, FundsWithdrawn) to and from Data Transfer Objects (DTOs) used by external ports. It also provides the concrete repository implementation (BankAccountRepositoryImpl) that handles account storage and ID generation via Spring components, and an event publisher (EventPublisherImpl) that routes domain events to the underlying event bus.

core/src/main/java/com/optivem/kata/banking/core/internal/cleanarch/acl · high confidence

The core module now exposes clean-architecture use cases for opening bank accounts, depositing and withdrawing funds, and viewing account details. These new handlers implement the pipelinr command pattern, integrating with the bank account repository, national identity and customer gateways for validation, and an event publisher to emit domain events such as AccountOpened, FundsDeposited, and FundsWithdrawn upon successful operations.

core/src/main/java/com/optivem/kata/banking/core/internal/cleanarch/usecases · high confidence

The core domain layer now includes a complete set of account-related value objects (AccountId, AccountNumber, Balance, Money, Text) and entities (BankAccount, ESBankAccount) with validation guards. It also introduces a credit scoring system with FactorCalculators (Name, Balance, Time) aggregated into a DefaultScoreCalculator that returns A, B, or C grades. Additionally, event sourcing support is added via domain events (AccountOpened, FundsDeposited, FundsWithdrawn) and an EventPublisher interface, alongside a BankAccountRepository interface for persistence abstraction.

core/src/main/java/com/optivem/kata/banking/core/internal/cleanarch/domain · high confidence

The z-customer-microservice now exposes a REST endpoint at /customers/{id} to retrieve customer details, returning a 404 status if the customer is not found. The service implementation uses an in-memory store and is accompanied by provider contract tests (Pact) that verify the API behavior against defined consumer contracts for blacklisted, whitelisted, and non-existent customer states.

z-customer-microservice · high confidence

The repository is initialized as a Java-based Banking Kata implementing a Use Case Driven Clean Architecture. It includes a \docker-compose.yml\ defining infrastructure services (PostgreSQL, MongoDB, Keycloak, Redis, RabbitMQ) and a \startup\ module to run the application. The project structure separates the Application Core (ports and internals) from Adapter layers (REST, persistence, messaging). It also introduces a comprehensive testing and quality suite, including Gradle wrapper scripts, unit/integration/system test execution tasks, code coverage (JaCoCo), and mutation testing (Pitest), alongside documentation for contribution and environment setup.

(repo-wide) · high confidence

This change introduces the foundational configuration files and infrastructure definitions required to run the application. It adds Spring Boot profiles for authentication (Keycloak), messaging (RabbitMQ), and persistence (JDBC, JPA, Redis), along with a default application profile activating JPA, Redis, and simulation adapters. It also includes a Keycloak realm export for identity management, RabbitMQ definitions for queues and exchanges, and helper scripts for PostgreSQL database initialization.

startup/src/main/resources · high confidence

The test fixtures module now includes a new UseCaseFactory interface and two concrete implementations (CleanArchUseCaseFactory and CrudUseCaseFactory) to instantiate banking use cases. CleanArchUseCaseFactory wires use cases like OpenAccount, DepositFunds, and WithdrawFunds with Clean Architecture components such as BankAccountRepositoryImpl and EventPublisherImpl, while CrudUseCaseFactory provides a simpler implementation that only supports OpenAccount. This change enables the test fixtures to support both Clean Architecture and CRUD-based implementations for contract testing purposes.

test-fixtures/src/main/java/com/optivem/kata/banking/core/common/factories · high confidence

A new Facade class has been added to the core module to serve as the primary entry point for banking operations. It consolidates access to key use cases—depositing funds, opening accounts, and viewing account details—by instantiating and delegating to their respective implementations. This component wires together underlying dependencies such as the national identity gateway, customer gateway, account ID/number generators, date/time service, bank account storage, and event bus, providing a simplified interface for external consumers to interact with the banking domain logic.

core/src/main/java/com/optivem/kata/banking/core · high confidence

The core module now exposes a set of driver port interfaces (requests and responses) for account operations, including opening accounts, viewing account details, depositing funds, and withdrawing funds. These contracts utilize the Pipelinr library for command handling and define the specific data structures exchanged between the application layer and external drivers. Additionally, a centralized validation messages class has been added to standardize error messaging for scenarios such as empty national identity numbers, negative balances, and insufficient funds, ensuring consistent user-facing error handling across these operations.

core/src/main/java/com/optivem/kata/banking/core/ports/driver · high confidence

The system now supports storing and retrieving bank account data using MongoDB. This change introduces a new persistence layer that maps bank account details to a MongoDB collection, enabling the application to save, find, and update account information via a Spring Data MongoDB template. The implementation includes the necessary document models and a custom data accessor to handle the MongoDB connection, activated via a specific Spring profile.

adapter-persistence-mongo · high confidence

Added \Verifications\ and \MethodSources\ classes to the test fixtures module. \Verifications\ provides static factory methods to create verification wrappers for executables, command handlers, and facades, while \MethodSources\ supplies standard streams of test data (such as null/empty strings and negative integers) to support parameterized tests.

test-fixtures/src/main/java/com/optivem/kata/banking/core/common · high confidence

The core module now includes a new validation guard system (Guard, BaseGuard, IntGuard, LongGuard, StringGuard) to enforce input constraints such as non-null, non-negative, and non-whitespace checks, throwing ValidationException on failure. Additionally, the OpenAccountUseCase has been implemented to handle account opening requests, utilizing these guards for validation, checking national identity existence and blacklist status via gateways, generating account details, persisting the account, publishing an event, and returning the account number.

core/src/main/java/com/optivem/kata/banking/core/internal/crud · high confidence

The adapter-microservice-real module now includes a concrete implementation of the CustomerGateway that communicates with an external customer provider service. This change introduces a new RealCustomerGateway component which uses Spring WebClient to fetch customer details (specifically blacklisting status) via HTTP GET requests to a configurable URI. A corresponding DTO (CustomerDto) is added to map the JSON response, and consumer contract tests (Pact) are implemented to verify the interaction protocol with the provider for blacklisted, whitelisted, and non-existent customer scenarios.

adapter-microservice-real · high confidence

The main Spring Boot application class (BankingApplication) has been moved into the startup module. This change establishes the application's entry point within the new modular structure, ensuring the Spring context is correctly initialized from this location.

startup/src/main/java · high confidence

This change adds a set of new interfaces and DTOs to the core module's driven ports layer, establishing the contracts for external dependencies and internal event publishing. Specifically, it defines \BankAccountStorage\ for account persistence, \CustomerGateway\ and \NationalIdentityGateway\ for identity verification, and generic generators for account IDs and numbers. It also introduces an \EventBus\ interface along with specific event DTOs (\AccountOpenedDto\, \FundsDepositedDto\, \FundsWithdrawnDto\) to support domain events for account opening and fund movements, alongside a \DateTimeService\ for time abstraction.

core/src/main/java/com/optivem/kata/banking/core/ports/driven · high confidence

The fake adapter implementation for the customer domain has been renamed from CustomerProvider to CustomerGateway to align with the core port interface. This change includes the new FakeCustomerGateway class, its Spring Boot simulator wrapper (FakeCustomerGatewaySimulator), and the corresponding contract test (FakeCustomerGatewayTest), ensuring the adapter correctly implements the CustomerGateway contract for blacklisting checks.

adapter-microservice-fake · high confidence

The Spring REST adapter now routes incoming HTTP requests through a Pipelinr command pipeline (configured in PipelinrConfiguration and accessed via BaseController) instead of direct service calls. This change is accompanied by the introduction of a BankingClient for external banking API interactions and a flexible security model that allows switching between no authentication, fake basic auth, and real OAuth2/JWT validation via Spring profiles (NoSecurityConfiguration, FakeSecurityConfiguration, SecurityConfiguration). Additionally, a DomainConfiguration bean wires the ScoreCalculator, and contract tests verify the BankingClient's behavior against a mock provider.

adapter-restapi-spring · high confidence

The adapter-base module now provides a centralized ProfileNames class containing static constants for all supported adapter profiles (such as persistence, auth, and messaging types), ensuring consistent profile naming across the application. Additionally, a set of abstract base test classes has been added to standardize contract testing for driven adapters, covering BankAccountStorage, CustomerGateway, EventBus, Generator, and NationalIdentityGateway behaviors.

adapter-base · high confidence

Added JPA-specific bank account storage contract test; Added contract test for National Identity Gateway provider; Added contract, system, and application tests for the banking adapter; Added facade-level tests for depositing funds; Added tests for FakeAccountNumberGenerator; Added tests for utility class instantiation patterns; Added unit tests for banking domain entities and scoring logic; Added unit tests for core banking use cases; Added unit tests for fake generator adapters and internal utilities; New test fixture builders and verification helpers for banking operations.

The project now includes a Gradle wrapper configuration file that specifies the use of Gradle version 7.4.1. This ensures that all users and build environments will automatically download and use this specific version of the Gradle build tool, promoting consistency across development and CI/CD pipelines.

gradle · high confidence

The project has been restructured from a single module into a multi-module Gradle build, introducing distinct modules for core logic, test fixtures, and various adapters (persistence, messaging, REST API, time, generation, microservices, and third-party integrations). This separation allows for independent compilation and testing of components, with the startup module acting as the assembly point that wires together specific adapter implementations like JPA, MongoDB, Redis, and RabbitMQ.

(dependencies) · high confidence

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

• CAI 36 → 48 (+11.5)
• Rubric changed (rubric-2026.08.17 → rubric-2026.09.15) — scores are not directly comparable.

• Code Health 100 → 95 (-4.2)
• Architecture 100 → 82 (-18.1)
• Maturity 58 → 59 (+0.9)
• Readiness 25 → 28 (+2.9)
• Security 16 → 57 (+40.8)
• Domain Modelling 100 → 81 (-18.8)

• Coverage not included — suite not readable by the collector
• Dependency hygiene not measured — no supported dependency manifest was read
• Duplicated block (10 lines × 2) (core/src/main/java/com/optivem/kata/banking/core/internal/cleanarch/domain/accounts/BankAccount.java)
• Duplicated block (8 lines × 2) (adapter-persistence-jpa/src/main/java/com/optivem/kata/banking/adapter/driven/persistence/jpa/JpaBankAccountStorage.java)
• High: security finding (details withheld)
• High: security finding (details withheld)
• High: security finding (details withheld)
• High: security finding (details withheld)
• High: security finding (details withheld)
• High: security finding (details withheld)
• No exposed public API
• Secret: generic-api-key (.github/workflows/ci.yaml)
• Secret: generic-api-key (.github/workflows/ci.yaml)
• Secret: generic-api-key (.github/workflows/sonar.yaml)
• Secret: generic-api-key (.github/workflows/sonar.yaml)
• Secret: generic-api-key (env/.env.local)
• Secret: generic-api-key (env/.env.local)
• Secret: generic-api-key (env/env.intellij.ui)
• Secret: generic-api-key (env/env.intellij.ui)
• Secret: generic-api-key (env/env.ps1)
• …and 3 more

• Boundary-crossing change coupling: ApplicationEventBus.java ↔ FacadeFactory.java (adapter-messaging-inmemory/src/main/java/com/optivem/kata/banking/adapter/driven/messaging/inmemory/ApplicationEventBus.java)
• Change coupling: DepositFundsRequestBuilder.java ↔ OpenAccountRequestBuilder.java (test-fixtures/src/main/java/com/optivem/kata/banking/core/common/builders/requests/DepositFundsRequestBuilder.java)
• Change coupling: DepositFundsUseCase.java ↔ WithdrawFundsUseCase.java (core/src/main/java/com/optivem/kata/banking/core/internal/cleanarch/usecases/DepositFundsUseCase.java)
• Change coupling: OpenAccountUseCase.java ↔ FacadeFactory.java (core/src/main/java/com/optivem/kata/banking/core/internal/crud/usecases/OpenAccountUseCase.java)
• Change coupling: RandomAccountIdGenerator.java ↔ RandomAccountNumberGenerator.java (adapter-generation-random/src/main/java/com/optivem/kata/banking/adapter/driven/generation/random/RandomAccountIdGenerator.java)
• 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 (12 lines × 2) (core/src/main/java/com/optivem/kata/banking/core/internal/cleanarch/domain/accounts/BankAccount.java)
• Duplicated block (12 lines × 2) (core/src/main/java/com/optivem/kata/banking/core/internal/cleanarch/domain/common/guards/LongGuard.java)
• Duplicated block (7 lines × 2) (core/src/main/java/com/optivem/kata/banking/core/internal/cleanarch/acl/FundsDepositedConverter.java)
• Duplicated block (7 lines × 2) (core/src/main/java/com/optivem/kata/banking/core/internal/cleanarch/domain/accounts/BankAccount.java)
• Duplicated block (8 lines × 2) (adapter-persistence-jpa/src/main/java/com/optivem/kata/banking/adapter/driven/persistence/jpa/JpaBankAccountStorage.java)
• High: security finding (details withheld)
• High: security finding (details withheld)
• High: security finding (details withheld)
• High: security finding (details withheld)
• High: security finding (details withheld)
• High: security finding (details withheld)
• …and 112 more

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

valentinajemuovic/banking-kata-java 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.