Codebase Analysis Tools (CAT) Report JSON

Statistics JSON

Project Name legacy-bank-app-main
Snapshot Date 04/01/2026, 11:12:04
LLM Provider VertexAI Gemini (Gemini Embeddings, Gemini Pro 3.0, Gemini Pro 2.5)
Files Count 93
Lines of Code 18321

Technologies JSON

Java EE 5 JBoss Application Server 4.2.3.GA Oracle Database 21c XE Java Server Pages (JSP) Enterprise JavaBeans (EJB) JAX-WS (SOAP) PL/SQL Shell Scripting (Bash) Docker

Description JSON

The Legacy Banking Application is a comprehensive, monolithic enterprise system designed to manage core banking operations. It is built upon a legacy Java EE technology stack, specifically utilizing Java 6/8 compatibility and running on the JBoss 4.2.3.GA application server. The application's architecture is heavily data-centric, relying on an Oracle 21c XE database not just for storage, but for critical business logic execution via PL/SQL stored procedures. The frontend is constructed using Java Server Pages (JSP) which frequently demonstrate the anti-pattern of embedding direct database queries within the presentation layer. The backend logic is distributed across Stateless Session EJBs (Enterprise JavaBeans) and standard Java Servlets, which act as controllers. These components are tightly coupled to the database schema, often invoking stored procedures for operations like account creation, transaction processing, and loan approval. The system handles a wide array of domain entities including Customers, Accounts, Transactions, Loans, and Branch information. Integration capabilities are provided through a SOAP-based web service (BankingService) using JAX-WS. Batch processing is implemented via shell scripts that invoke SQL*Plus to trigger database-side logic for end-of-day reconciliation and interest calculations. The application enforces business rules such as KYC validation and balance checks, often implemented within database triggers or complex SQL queries. Security and auditing are managed through database triggers that populate audit log tables. The system is containerized using Docker, orchestrating the JBoss application server and the Oracle database. This application serves as a prime example of legacy architecture requiring modernization, showcasing tight coupling, logic leakage into the database, and monolithic deployment artifacts.

File Types JSON

25.8% 21.5% 18.3% 11.8% 7.5% 6.5% 4.3% java (24 files) jsp (20 files) sh (17 files) sql (11 files) xml (7 files) md (6 files) pkg (4 files) jboss (1 files) wsdl (1 files) yml (1 files) oracle (1 files)

File Type Files Count Lines Count
java 24 3563
jsp 20 6527
sh 17 2600
sql 11 2509
xml 7 328
md 6 999
pkg 4 1403
jboss 1 147
wsdl 1 142
yml 1 56
oracle 1 47

Bill of Materials (Dependencies) JSON

Total Dependencies 5
Version Conflicts 0
Build Files 1
Dependency Name Group ID Versions Scopes Locations Status
*.jar (JBoss Core Libraries) jboss.home/lib provided 1 file ✓ OK
*.jar (JBoss Server Libraries) jboss.home/server/default/lib provided 1 file ✓ OK
*.jar (Local Project Libraries) lib.dir compile 1 file ✓ OK
jsp-api.jar javax.servlet.jsp provided 1 file ✓ OK
servlet-api.jar javax.servlet provided 1 file ✓ OK

Existing Business Processes JSON

Customer Onboarding process

The process of registering a new customer into the banking system, verifying their identity, and establishing their profile. This involves collecting personal details, validating KYC status, and persisting the customer record. It is the prerequisite for opening accounts or applying for loans.

%%{init: {'flowchart': {'diagramPadding': 30}}}%%
graph LR

    classDef boundedContext fill:#e8f5e8,stroke:#00684A,stroke-width:3px,color:#001e2b
    classDef aggregate fill:#e3f2fd,stroke:#1976d2,stroke-width:2px,color:#001e2b
    classDef entity fill:#f3e5f5,stroke:#7b1fa2,stroke-width:1.5px,color:#001e2b
    classDef repository fill:#fff5f0,stroke:#d2691e,stroke-width:1.5px,color:#001e2b
    classDef service fill:#ffffff,stroke:#00684A,stroke-width:2px,color:#001e2b
    classDef process fill:#ffffff,stroke:#00684A,stroke-width:2px,color:#001e2b
    classDef dependency fill:#f8f9fa,stroke:#6c757d,stroke-width:1px,color:#001e2b
    classDef rootDependency fill:#e3f2fd,stroke:#1976d2,stroke-width:2px,color:#001e2b
    classDef internalComponent fill:#e8f5e8,stroke:#00684A,stroke-width:2px,color:#001e2b
    classDef externalComponent fill:#fff3e0,stroke:#e65100,stroke-width:2px,color:#001e2b
    capture_customer_data_0["Capture Customer Data"]
    class capture_customer_data_0 process
    kyc_validation_1["KYC Validation"]
    class kyc_validation_1 process
    profile_creation_2["Profile Creation"]
    class profile_creation_2 process
    capture_customer_data_0 --> kyc_validation_1
    kyc_validation_1 --> profile_creation_2

Process Activities:

  • Capture Customer Data Collection of personal information including name, SSN, DOB, and contact details via the Customer Form.
  • KYC Validation Verification of the customer's Know Your Customer status to ensure compliance before allowing banking services.
  • Profile Creation Persisting the customer entity into the database and generating a unique Customer ID.

Account Origination process

The lifecycle of opening a new financial account for an existing customer. This process links a customer to a specific branch, defines the account type (Checking, Savings, etc.), and handles the initial funding. It relies on stored procedures to ensure data integrity during creation.

%%{init: {'flowchart': {'diagramPadding': 30}}}%%
graph LR

    classDef boundedContext fill:#e8f5e8,stroke:#00684A,stroke-width:3px,color:#001e2b
    classDef aggregate fill:#e3f2fd,stroke:#1976d2,stroke-width:2px,color:#001e2b
    classDef entity fill:#f3e5f5,stroke:#7b1fa2,stroke-width:1.5px,color:#001e2b
    classDef repository fill:#fff5f0,stroke:#d2691e,stroke-width:1.5px,color:#001e2b
    classDef service fill:#ffffff,stroke:#00684A,stroke-width:2px,color:#001e2b
    classDef process fill:#ffffff,stroke:#00684A,stroke-width:2px,color:#001e2b
    classDef dependency fill:#f8f9fa,stroke:#6c757d,stroke-width:1px,color:#001e2b
    classDef rootDependency fill:#e3f2fd,stroke:#1976d2,stroke-width:2px,color:#001e2b
    classDef internalComponent fill:#e8f5e8,stroke:#00684A,stroke-width:2px,color:#001e2b
    classDef externalComponent fill:#fff3e0,stroke:#e65100,stroke-width:2px,color:#001e2b
    account_application_0["Account Application"]
    class account_application_0 process
    initial_deposit_processing_1["Initial Deposit Processing"]
    class initial_deposit_processing_1 process
    account_activation_2["Account Activation"]
    class account_activation_2 process
    account_application_0 --> initial_deposit_processing_1
    initial_deposit_processing_1 --> account_activation_2

Process Activities:

  • Account Application Selection of account type, branch assignment, and interest rate configuration.
  • Initial Deposit Processing Handling the initial monetary deposit required to activate the account.
  • Account Activation Generating the account number and setting the account status to ACTIVE.

Loan Lifecycle Management process

Manages the end-to-end process of lending, from application to approval and repayment. This process involves assessing customer eligibility, calculating terms and interest, and managing monthly payments. It utilizes complex logic to track principal and interest portions of payments.

%%{init: {'flowchart': {'diagramPadding': 30}}}%%
graph LR

    classDef boundedContext fill:#e8f5e8,stroke:#00684A,stroke-width:3px,color:#001e2b
    classDef aggregate fill:#e3f2fd,stroke:#1976d2,stroke-width:2px,color:#001e2b
    classDef entity fill:#f3e5f5,stroke:#7b1fa2,stroke-width:1.5px,color:#001e2b
    classDef repository fill:#fff5f0,stroke:#d2691e,stroke-width:1.5px,color:#001e2b
    classDef service fill:#ffffff,stroke:#00684A,stroke-width:2px,color:#001e2b
    classDef process fill:#ffffff,stroke:#00684A,stroke-width:2px,color:#001e2b
    classDef dependency fill:#f8f9fa,stroke:#6c757d,stroke-width:1px,color:#001e2b
    classDef rootDependency fill:#e3f2fd,stroke:#1976d2,stroke-width:2px,color:#001e2b
    classDef internalComponent fill:#e8f5e8,stroke:#00684A,stroke-width:2px,color:#001e2b
    classDef externalComponent fill:#fff3e0,stroke:#e65100,stroke-width:2px,color:#001e2b
    loan_application_0["Loan Application"]
    class loan_application_0 process
    credit_approval_1["Credit Approval"]
    class credit_approval_1 process
    disbursement_2["Disbursement"]
    class disbursement_2 process
    repayment_processing_3["Repayment Processing"]
    class repayment_processing_3 process
    loan_application_0 --> credit_approval_1
    credit_approval_1 --> disbursement_2
    disbursement_2 --> repayment_processing_3

Process Activities:

  • Loan Application Submission of loan request details including type, principal amount, and desired term.
  • Credit Approval Review of the application by an authorized employee and updating the status to APPROVED.
  • Disbursement Crediting the loan principal to the customer's linked account upon activation.
  • Repayment Processing Processing periodic payments, splitting amounts between interest and principal reduction.

Transaction Processing process

The core operational process of moving funds within the bank. This includes deposits, withdrawals, and transfers between accounts. It ensures ACID properties are maintained and balances are updated atomically.

%%{init: {'flowchart': {'diagramPadding': 30}}}%%
graph LR

    classDef boundedContext fill:#e8f5e8,stroke:#00684A,stroke-width:3px,color:#001e2b
    classDef aggregate fill:#e3f2fd,stroke:#1976d2,stroke-width:2px,color:#001e2b
    classDef entity fill:#f3e5f5,stroke:#7b1fa2,stroke-width:1.5px,color:#001e2b
    classDef repository fill:#fff5f0,stroke:#d2691e,stroke-width:1.5px,color:#001e2b
    classDef service fill:#ffffff,stroke:#00684A,stroke-width:2px,color:#001e2b
    classDef process fill:#ffffff,stroke:#00684A,stroke-width:2px,color:#001e2b
    classDef dependency fill:#f8f9fa,stroke:#6c757d,stroke-width:1px,color:#001e2b
    classDef rootDependency fill:#e3f2fd,stroke:#1976d2,stroke-width:2px,color:#001e2b
    classDef internalComponent fill:#e8f5e8,stroke:#00684A,stroke-width:2px,color:#001e2b
    classDef externalComponent fill:#fff3e0,stroke:#e65100,stroke-width:2px,color:#001e2b
    transaction_validation_0["Transaction Validation"]
    class transaction_validation_0 process
    fund_movement_1["Fund Movement"]
    class fund_movement_1 process
    audit_logging_2["Audit Logging"]
    class audit_logging_2 process
    transaction_validation_0 --> fund_movement_1
    fund_movement_1 --> audit_logging_2

Process Activities:

  • Transaction Validation Checking account status and available balance before authorizing a transaction.
  • Fund Movement Executing the debit and credit operations against the respective account balances.
  • Audit Logging Recording the transaction details and updating the account's last activity timestamp.

End of Day Processing process

A batch-oriented process that runs periodically to perform maintenance tasks. This includes calculating daily interest for eligible accounts and generating system-wide reports. It is triggered externally via shell scripts.

%%{init: {'flowchart': {'diagramPadding': 30}}}%%
graph LR

    classDef boundedContext fill:#e8f5e8,stroke:#00684A,stroke-width:3px,color:#001e2b
    classDef aggregate fill:#e3f2fd,stroke:#1976d2,stroke-width:2px,color:#001e2b
    classDef entity fill:#f3e5f5,stroke:#7b1fa2,stroke-width:1.5px,color:#001e2b
    classDef repository fill:#fff5f0,stroke:#d2691e,stroke-width:1.5px,color:#001e2b
    classDef service fill:#ffffff,stroke:#00684A,stroke-width:2px,color:#001e2b
    classDef process fill:#ffffff,stroke:#00684A,stroke-width:2px,color:#001e2b
    classDef dependency fill:#f8f9fa,stroke:#6c757d,stroke-width:1px,color:#001e2b
    classDef rootDependency fill:#e3f2fd,stroke:#1976d2,stroke-width:2px,color:#001e2b
    classDef internalComponent fill:#e8f5e8,stroke:#00684A,stroke-width:2px,color:#001e2b
    classDef externalComponent fill:#fff3e0,stroke:#e65100,stroke-width:2px,color:#001e2b
    interest_calculation_0["Interest Calculation"]
    class interest_calculation_0 process
    balance_reconciliation_1["Balance Reconciliation"]
    class balance_reconciliation_1 process
    statement_generation_2["Statement Generation"]
    class statement_generation_2 process
    interest_calculation_0 --> balance_reconciliation_1
    balance_reconciliation_1 --> statement_generation_2

Process Activities:

  • Interest Calculation Computing compound interest for Savings and Money Market accounts based on daily balances.
  • Balance Reconciliation Verifying that account balances match the sum of their transaction history.
  • Statement Generation Creating monthly statement files for customers detailing their transaction history.

Current Architecture JSON

Note: This diagram shows the high-level business components inferred from the existing codebase. Internal components (green) represent core business functionality, while external dependencies (orange) represent external systems such as databases, message queues, and external APIs.

Architecture Overview

%%{init: {'flowchart': {'diagramPadding': 50, 'nodeSpacing': 30, 'rankSpacing': 60}}}%%
flowchart TB

    classDef boundedContext fill:#e8f5e8,stroke:#00684A,stroke-width:3px,color:#001e2b
    classDef aggregate fill:#e3f2fd,stroke:#1976d2,stroke-width:2px,color:#001e2b
    classDef entity fill:#f3e5f5,stroke:#7b1fa2,stroke-width:1.5px,color:#001e2b
    classDef repository fill:#fff5f0,stroke:#d2691e,stroke-width:1.5px,color:#001e2b
    classDef service fill:#ffffff,stroke:#00684A,stroke-width:2px,color:#001e2b
    classDef process fill:#ffffff,stroke:#00684A,stroke-width:2px,color:#001e2b
    classDef dependency fill:#f8f9fa,stroke:#6c757d,stroke-width:1px,color:#001e2b
    classDef rootDependency fill:#e3f2fd,stroke:#1976d2,stroke-width:2px,color:#001e2b
    classDef internalComponent fill:#e8f5e8,stroke:#00684A,stroke-width:2px,color:#001e2b
    classDef externalComponent fill:#fff3e0,stroke:#e65100,stroke-width:2px,color:#001e2b
    int_account_manager_0["Account Manager"]
    int_transaction_processor_1["Transaction Processor"]
    int_loan_manager_2["Loan Manager"]
    int_customer_manager_3["Customer Manager"]
    int_branch_manager_4["Branch Manager"]
    int_interest_calculator_5["Interest Calculator"]
    int_statement_generator_6["Statement Generator"]
    int_card_manager_7["Card Manager"]
    int_bill_pay_service_8["Bill Pay Service"]
    int_audit_logger_9["Audit Logger"]
    ext_oracle_database_0["Oracle Database
Database"]
    ext_local_file_system_1["Local File System
File System"]
    int_account_manager_0 --> ext_oracle_database_0
    int_transaction_processor_1 --> ext_oracle_database_0
    int_loan_manager_2 --> ext_oracle_database_0
    int_customer_manager_3 --> ext_oracle_database_0
    int_branch_manager_4 --> ext_oracle_database_0
    int_interest_calculator_5 --> ext_oracle_database_0
    int_statement_generator_6 --> ext_oracle_database_0
    int_statement_generator_6 --> ext_local_file_system_1
    int_card_manager_7 --> ext_oracle_database_0
    int_bill_pay_service_8 --> ext_oracle_database_0
    int_audit_logger_9 --> ext_oracle_database_0
    int_transaction_processor_1 --> int_account_manager_0
    int_loan_manager_2 --> int_account_manager_0
    int_loan_manager_2 --> int_customer_manager_3
    int_account_manager_0 --> int_customer_manager_3
    int_account_manager_0 --> int_branch_manager_4
    class int_account_manager_0 internalComponent
    class int_transaction_processor_1 internalComponent
    class int_loan_manager_2 internalComponent
    class int_customer_manager_3 internalComponent
    class int_branch_manager_4 internalComponent
    class int_interest_calculator_5 internalComponent
    class int_statement_generator_6 internalComponent
    class int_card_manager_7 internalComponent
    class int_bill_pay_service_8 internalComponent
    class int_audit_logger_9 internalComponent
    class ext_oracle_database_0 externalComponent
    class ext_local_file_system_1 externalComponent

Internal Business Components

Account Manager

Responsible for the lifecycle of bank accounts. It handles creation, status updates (closing/freezing), and retrieving account details. It interacts heavily with the database to maintain balance consistency.

Transaction Processor

Manages the execution of financial transactions such as deposits, withdrawals, and transfers. It ensures that funds are available before processing and maintains an audit trail of all movements.

Loan Manager

Handles the lending business capability. It processes loan applications, manages the approval workflow, calculates monthly payments, and tracks the remaining balance and interest.

Customer Manager

Manages customer identity and profiles. It handles onboarding, KYC verification status, and updates to personal contact information.

Branch Manager

Manages the physical branch locations and the employees assigned to them. It provides data regarding where accounts are held and where staff are located.

Interest Calculator

A batch-oriented component responsible for calculating compound interest for savings and money market accounts. It runs periodically to credit interest to eligible accounts.

Statement Generator

A batch component that generates monthly account statements for customers. It aggregates transaction history for a specific period into a report format.

Card Manager

Manages the lifecycle of debit and credit cards linked to accounts. It handles card issuance, status tracking, and transaction authorization.

Bill Pay Service

Manages scheduled and recurring payments to external payees. It tracks payment schedules and executes transfers from customer accounts.

Audit Logger

Captures and records changes to critical data entities. It ensures compliance and security by logging who changed what and when.

External Dependencies

Name Type Description
Oracle Database Database The primary persistence store and execution engine for business logic (via PL/SQL). All internal components depend on this for state and processing.
Local File System File System Used by the Statement Generator to output generated monthly statement files.

Derived Microservices Architecture JSON

Note: This is a suggested new Microservices architecture derived from what the application does and how it functions - it intentionally does not reflect the curent the current archiecture of the application or any of its existing Microservices (if any).

Microservices

%%{init: {'flowchart': {'diagramPadding': 30}}}%%
flowchart TB

    classDef boundedContext fill:#e8f5e8,stroke:#00684A,stroke-width:3px,color:#001e2b
    classDef aggregate fill:#e3f2fd,stroke:#1976d2,stroke-width:2px,color:#001e2b
    classDef entity fill:#f3e5f5,stroke:#7b1fa2,stroke-width:1.5px,color:#001e2b
    classDef repository fill:#fff5f0,stroke:#d2691e,stroke-width:1.5px,color:#001e2b
    classDef service fill:#ffffff,stroke:#00684A,stroke-width:2px,color:#001e2b
    classDef process fill:#ffffff,stroke:#00684A,stroke-width:2px,color:#001e2b
    classDef dependency fill:#f8f9fa,stroke:#6c757d,stroke-width:1px,color:#001e2b
    classDef rootDependency fill:#e3f2fd,stroke:#1976d2,stroke-width:2px,color:#001e2b
    classDef internalComponent fill:#e8f5e8,stroke:#00684A,stroke-width:2px,color:#001e2b
    classDef externalComponent fill:#fff3e0,stroke:#e65100,stroke-width:2px,color:#001e2b
    subgraph services[" "]
        account_service_0["Account Service"]
        transaction_service_1["Transaction Service"]
        customer_service_2["Customer Service"]
        loan_service_3["Loan Service"]
        account_service_0 ~~~ transaction_service_1
        transaction_service_1 ~~~ customer_service_2
        account_service_0 ~~~ loan_service_3
    end
    class account_service_0 service
    class transaction_service_1 service
    class customer_service_2 service
    class loan_service_3 service
    style services fill:transparent,stroke:transparent,stroke-width:0

Microservices Details

Account Service

A core service responsible for managing the lifecycle of bank accounts. It will handle account creation, balance inquiries, and status updates. It will abstract the legacy 'account_management' stored procedures into Java-based business logic.

Entities
  • Account: Represents a financial account.
    Attributes: accountId, accountNumber, balance, type, status
API Endpoints
  • POST /api/accounts
    Create a new account for a customer.
  • GET /api/accounts/{id}
    Retrieve details and balance for a specific account.
  • PATCH /api/accounts/{id}/status
    Update the status of an account (e.g., freeze, close).
Operations
  • Create Account (POST)
    Validates customer and branch, generates account number, and initializes balance.
  • Get Balance (GET)
    Returns the current available balance.

Transaction Service

Handles all monetary movements including deposits, withdrawals, and transfers. It ensures transactional integrity and maintains the transaction history log. It replaces the 'transaction_processing' package.

Entities
  • Transaction: A record of a financial event.
    Attributes: transactionId, amount, type, timestamp, description
API Endpoints
  • POST /api/transactions
    Execute a new transaction (deposit, withdrawal, transfer).
  • GET /api/accounts/{accountId}/transactions
    Get transaction history for a specific account.
Operations
  • Post Transaction (POST)
    Validates funds and records the transaction.
  • Transfer Funds (POST)
    Atomically debits one account and credits another.

Customer Service

Manages customer profiles, KYC data, and contact information. It serves as the source of truth for customer identity.

Entities
  • Customer: The banking client.
    Attributes: customerId, firstName, lastName, ssn, kycStatus
API Endpoints
  • POST /api/customers
    Register a new customer.
  • GET /api/customers/{id}
    Retrieve customer profile details.
  • PUT /api/customers/{id}
    Update customer contact info or KYC status.
Operations
  • Onboard Customer (POST)
    Creates a new customer record.
  • Update Profile (PUT)
    Modifies customer details.

Loan Service

Manages loan applications, approvals, and amortization schedules. It replaces the 'loan_processing' stored procedures.

Entities
  • Loan: A lending agreement.
    Attributes: loanId, principal, interestRate, term, status
API Endpoints
  • POST /api/loans
    Submit a new loan application.
  • POST /api/loans/{id}/approval
    Approve a pending loan application.
  • POST /api/loans/{id}/payment
    Process a loan repayment.
Operations
  • Apply for Loan (POST)
    Creates a loan application.
  • Calculate Amortization (GET)
    Calculates monthly payments and interest.

Derived Domain Model JSON

Note: This domain model has been derived from what the application does and how it functions - it intentionally does not reflect how the current code manages and persists business data.

Account Management Context bounded context

This context encapsulates all capabilities related to the lifecycle and maintenance of financial accounts. It handles account creation, status management (freezing/closing), and balance tracking. It is the central hub for customer financial data.

%%{init: {'flowchart': {'diagramPadding': 30}}}%%
flowchart TB

    classDef boundedContext fill:#e8f5e8,stroke:#00684A,stroke-width:3px,color:#001e2b
    classDef aggregate fill:#e3f2fd,stroke:#1976d2,stroke-width:2px,color:#001e2b
    classDef entity fill:#f3e5f5,stroke:#7b1fa2,stroke-width:1.5px,color:#001e2b
    classDef repository fill:#fff5f0,stroke:#d2691e,stroke-width:1.5px,color:#001e2b
    classDef service fill:#ffffff,stroke:#00684A,stroke-width:2px,color:#001e2b
    classDef process fill:#ffffff,stroke:#00684A,stroke-width:2px,color:#001e2b
    classDef dependency fill:#f8f9fa,stroke:#6c757d,stroke-width:1px,color:#001e2b
    classDef rootDependency fill:#e3f2fd,stroke:#1976d2,stroke-width:2px,color:#001e2b
    classDef internalComponent fill:#e8f5e8,stroke:#00684A,stroke-width:2px,color:#001e2b
    classDef externalComponent fill:#fff3e0,stroke:#e65100,stroke-width:2px,color:#001e2b
    account_management_context_0{{"Account Management Context"}}
    account_management_context_0 --> agg_bankaccount_0
    agg_bankaccount_0 -.-> entity_account_0
    agg_bankaccount_0 -.-> entity_transaction_1
    subgraph aggRepoGroup0[" "]
        direction LR
        agg_bankaccount_0(["BankAccount"])
        repo_accountrepository_0(("AccountRepository"))
        agg_bankaccount_0 -.- repo_accountrepository_0
    end
    class agg_bankaccount_0 aggregate
    class repo_accountrepository_0 repository
    subgraph entitiesGroup[" "]
        direction LR
        entity_account_0("Account")
        entity_transaction_1("Transaction")
    end
    class entity_account_0 entity
    class entity_transaction_1 entity
    class account_management_context_0 boundedContext
    style aggRepoGroup0 fill:transparent,stroke:transparent,stroke-width:0
    style entitiesGroup fill:transparent,stroke:transparent,stroke-width:0

Aggregates (1)

  • BankAccount: The core aggregate representing a customer's financial holding. It enforces rules regarding minimum balances, valid account types, and status transitions.

Repositories (1)

  • AccountRepository: Handles persistence for Account entities, providing methods to find accounts by ID, customer, or account number.

Entities (2)

  • Account: The root entity containing balance, type (Checking/Savings), and status.
  • Transaction: A record of financial movement affecting the account balance.

Lending Context bounded context

Focuses on the borrowing aspect of the banking business. It manages the entire loan lifecycle from application to payoff, including interest rates, terms, and repayment schedules.

%%{init: {'flowchart': {'diagramPadding': 30}}}%%
flowchart TB

    classDef boundedContext fill:#e8f5e8,stroke:#00684A,stroke-width:3px,color:#001e2b
    classDef aggregate fill:#e3f2fd,stroke:#1976d2,stroke-width:2px,color:#001e2b
    classDef entity fill:#f3e5f5,stroke:#7b1fa2,stroke-width:1.5px,color:#001e2b
    classDef repository fill:#fff5f0,stroke:#d2691e,stroke-width:1.5px,color:#001e2b
    classDef service fill:#ffffff,stroke:#00684A,stroke-width:2px,color:#001e2b
    classDef process fill:#ffffff,stroke:#00684A,stroke-width:2px,color:#001e2b
    classDef dependency fill:#f8f9fa,stroke:#6c757d,stroke-width:1px,color:#001e2b
    classDef rootDependency fill:#e3f2fd,stroke:#1976d2,stroke-width:2px,color:#001e2b
    classDef internalComponent fill:#e8f5e8,stroke:#00684A,stroke-width:2px,color:#001e2b
    classDef externalComponent fill:#fff3e0,stroke:#e65100,stroke-width:2px,color:#001e2b
    lending_context_0{{"Lending Context"}}
    lending_context_0 --> agg_loanagreement_0
    agg_loanagreement_0 -.-> entity_loan_0
    agg_loanagreement_0 -.-> entity_loanpayment_1
    subgraph aggRepoGroup0[" "]
        direction LR
        agg_loanagreement_0(["LoanAgreement"])
        repo_loanrepository_0(("LoanRepository"))
        agg_loanagreement_0 -.- repo_loanrepository_0
    end
    class agg_loanagreement_0 aggregate
    class repo_loanrepository_0 repository
    subgraph entitiesGroup[" "]
        direction LR
        entity_loan_0("Loan")
        entity_loanpayment_1("LoanPayment")
    end
    class entity_loan_0 entity
    class entity_loanpayment_1 entity
    class lending_context_0 boundedContext
    style aggRepoGroup0 fill:transparent,stroke:transparent,stroke-width:0
    style entitiesGroup fill:transparent,stroke:transparent,stroke-width:0

Aggregates (1)

  • LoanAgreement: Represents a contract between the bank and a customer for borrowed funds. It enforces rules regarding approval workflows and repayment calculations.

Repositories (1)

  • LoanRepository: Manages the storage and retrieval of Loan applications and active loan records.

Entities (2)

  • Loan: The root entity detailing principal, interest rate, term, and remaining balance.
  • LoanPayment: A record of a repayment installment, split into principal and interest components.

Customer Context bounded context

Manages the identity and profile information of the bank's clients. It is responsible for KYC compliance, contact information, and relationship management.

%%{init: {'flowchart': {'diagramPadding': 30}}}%%
flowchart TB

    classDef boundedContext fill:#e8f5e8,stroke:#00684A,stroke-width:3px,color:#001e2b
    classDef aggregate fill:#e3f2fd,stroke:#1976d2,stroke-width:2px,color:#001e2b
    classDef entity fill:#f3e5f5,stroke:#7b1fa2,stroke-width:1.5px,color:#001e2b
    classDef repository fill:#fff5f0,stroke:#d2691e,stroke-width:1.5px,color:#001e2b
    classDef service fill:#ffffff,stroke:#00684A,stroke-width:2px,color:#001e2b
    classDef process fill:#ffffff,stroke:#00684A,stroke-width:2px,color:#001e2b
    classDef dependency fill:#f8f9fa,stroke:#6c757d,stroke-width:1px,color:#001e2b
    classDef rootDependency fill:#e3f2fd,stroke:#1976d2,stroke-width:2px,color:#001e2b
    classDef internalComponent fill:#e8f5e8,stroke:#00684A,stroke-width:2px,color:#001e2b
    classDef externalComponent fill:#fff3e0,stroke:#e65100,stroke-width:2px,color:#001e2b
    customer_context_0{{"Customer Context"}}
    customer_context_0 --> agg_customerprofile_0
    agg_customerprofile_0 -.-> entity_customer_0
    agg_customerprofile_0 -.-> entity_relationship_1
    subgraph aggRepoGroup0[" "]
        direction LR
        agg_customerprofile_0(["CustomerProfile"])
        repo_customerrepository_0(("CustomerRepository"))
        agg_customerprofile_0 -.- repo_customerrepository_0
    end
    class agg_customerprofile_0 aggregate
    class repo_customerrepository_0 repository
    subgraph entitiesGroup[" "]
        direction LR
        entity_customer_0("Customer")
        entity_relationship_1("Relationship")
    end
    class entity_customer_0 entity
    class entity_relationship_1 entity
    class customer_context_0 boundedContext
    style aggRepoGroup0 fill:transparent,stroke:transparent,stroke-width:0
    style entitiesGroup fill:transparent,stroke:transparent,stroke-width:0

Aggregates (1)

  • CustomerProfile: The aggregate for customer identity. It ensures unique identification (SSN) and validates contact data.

Repositories (1)

  • CustomerRepository: Provides access to customer records and supports searching by various attributes.

Entities (2)

  • Customer: The root entity containing personal details, KYC status, and demographics.
  • Relationship: Defines links between different customers (e.g., Spouse, Joint Account Holder).

Branch Operations Context bounded context

Deals with the physical infrastructure and staffing of the bank. It manages branch locations and the employees assigned to them.

%%{init: {'flowchart': {'diagramPadding': 30}}}%%
flowchart TB

    classDef boundedContext fill:#e8f5e8,stroke:#00684A,stroke-width:3px,color:#001e2b
    classDef aggregate fill:#e3f2fd,stroke:#1976d2,stroke-width:2px,color:#001e2b
    classDef entity fill:#f3e5f5,stroke:#7b1fa2,stroke-width:1.5px,color:#001e2b
    classDef repository fill:#fff5f0,stroke:#d2691e,stroke-width:1.5px,color:#001e2b
    classDef service fill:#ffffff,stroke:#00684A,stroke-width:2px,color:#001e2b
    classDef process fill:#ffffff,stroke:#00684A,stroke-width:2px,color:#001e2b
    classDef dependency fill:#f8f9fa,stroke:#6c757d,stroke-width:1px,color:#001e2b
    classDef rootDependency fill:#e3f2fd,stroke:#1976d2,stroke-width:2px,color:#001e2b
    classDef internalComponent fill:#e8f5e8,stroke:#00684A,stroke-width:2px,color:#001e2b
    classDef externalComponent fill:#fff3e0,stroke:#e65100,stroke-width:2px,color:#001e2b
    branch_operations_context_0{{"Branch Operations Context"}}
    branch_operations_context_0 --> agg_branchoffice_0
    agg_branchoffice_0 -.-> entity_branch_0
    agg_branchoffice_0 -.-> entity_employee_1
    subgraph aggRepoGroup0[" "]
        direction LR
        agg_branchoffice_0(["BranchOffice"])
        repo_branchrepository_0(("BranchRepository"))
        agg_branchoffice_0 -.- repo_branchrepository_0
    end
    class agg_branchoffice_0 aggregate
    class repo_branchrepository_0 repository
    subgraph entitiesGroup[" "]
        direction LR
        entity_branch_0("Branch")
        entity_employee_1("Employee")
    end
    class entity_branch_0 entity
    class entity_employee_1 entity
    class branch_operations_context_0 boundedContext
    style aggRepoGroup0 fill:transparent,stroke:transparent,stroke-width:0
    style entitiesGroup fill:transparent,stroke:transparent,stroke-width:0

Aggregates (1)

  • BranchOffice: Represents a physical bank location. It manages the association of employees and accounts to a specific location.

Repositories (1)

  • BranchRepository: Handles persistence for Branch and Employee data.

Entities (2)

  • Branch: The root entity defining the location and contact details of a bank branch.
  • Employee: Staff members assigned to a branch, including their roles and permissions.

Payment Services Context bounded context

Handles ancillary payment methods and external transfers. This includes bill payments and card management.

%%{init: {'flowchart': {'diagramPadding': 30}}}%%
flowchart TB

    classDef boundedContext fill:#e8f5e8,stroke:#00684A,stroke-width:3px,color:#001e2b
    classDef aggregate fill:#e3f2fd,stroke:#1976d2,stroke-width:2px,color:#001e2b
    classDef entity fill:#f3e5f5,stroke:#7b1fa2,stroke-width:1.5px,color:#001e2b
    classDef repository fill:#fff5f0,stroke:#d2691e,stroke-width:1.5px,color:#001e2b
    classDef service fill:#ffffff,stroke:#00684A,stroke-width:2px,color:#001e2b
    classDef process fill:#ffffff,stroke:#00684A,stroke-width:2px,color:#001e2b
    classDef dependency fill:#f8f9fa,stroke:#6c757d,stroke-width:1px,color:#001e2b
    classDef rootDependency fill:#e3f2fd,stroke:#1976d2,stroke-width:2px,color:#001e2b
    classDef internalComponent fill:#e8f5e8,stroke:#00684A,stroke-width:2px,color:#001e2b
    classDef externalComponent fill:#fff3e0,stroke:#e65100,stroke-width:2px,color:#001e2b
    payment_services_context_0{{"Payment Services Context"}}
    payment_services_context_0 --> agg_paymentinstrument_0
    agg_paymentinstrument_0 -.-> entity_card_0
    agg_paymentinstrument_0 -.-> entity_billpayment_1
    subgraph aggRepoGroup0[" "]
        direction LR
        agg_paymentinstrument_0(["PaymentInstrument"])
        repo_paymentrepository_0(("PaymentRepository"))
        agg_paymentinstrument_0 -.- repo_paymentrepository_0
    end
    class agg_paymentinstrument_0 aggregate
    class repo_paymentrepository_0 repository
    subgraph entitiesGroup[" "]
        direction LR
        entity_card_0("Card")
        entity_billpayment_1("BillPayment")
    end
    class entity_card_0 entity
    class entity_billpayment_1 entity
    class payment_services_context_0 boundedContext
    style aggRepoGroup0 fill:transparent,stroke:transparent,stroke-width:0
    style entitiesGroup fill:transparent,stroke:transparent,stroke-width:0

Aggregates (1)

  • PaymentInstrument: Manages cards and bill payment setups. It enforces limits and expiration dates.

Repositories (1)

  • PaymentRepository: Stores data related to debit/credit cards and bill payment schedules.

Entities (2)

  • Card: Represents a physical debit or credit card linked to an account.
  • BillPayment: A scheduled or recurring payment to an external payee.

Code Quality Summary JSON

This section provides code quality metrics to help identify complex, hard-to-maintain code. Metrics are estimated by AI and should be verified manually.

Overall Statistics

Metric Value Description
Total Functions/Methods Analyzed 323 Total number of functions/methods analyzed across the codebase
Average Complexity 1.36 Average cyclomatic complexity (1-10: simple, 11-20: moderate, >20: complex)
High Complexity Functions/Methods 1 Functions/methods with complexity > 10 (candidate for refactoring)
Very High Complexity 1 Functions/methods with complexity > 20 (high priority for refactoring)
Average Function/Method Length 5.92 LOC Average lines of code per function/method
Long Functions/Methods 3 Functions/methods with > 50 lines of code

Top 10 Most Complex Functions/Methods

These functions/methods have the highest cyclomatic complexity and should be prioritized for refactoring.

Function/Method Name File Path Complexity Lines Code Smells
doPost com.legacybank.servlet.CustomerServlet::doPost
CustomerServlet.java backend/src/servlet/CustomerServlet.java
22 88
  • LONG METHOD
  • COMPLEX CONDITIONAL
  • MAGIC NUMBERS
  • DEEP NESTING
getLoanPayments com.legacybank.ejb.LoanServiceBean::getLoanPayments
LoanServiceBean.java backend/src/ejb/LoanServiceBean.java
8 48
  • MAGIC NUMBERS
getLoanDetails com.legacybank.ejb.LoanServiceBean::getLoanDetails
LoanServiceBean.java backend/src/ejb/LoanServiceBean.java
8 63
  • LONG METHOD
  • MAGIC NUMBERS
doGet com.legacybank.servlet.AccountServlet::doGet
AccountServlet.java backend/src/servlet/AccountServlet.java
8 48
  • DUPLICATE CODE
  • MAGIC NUMBERS
  • COMPLEX CONDITIONAL
create com.legacybank.dao.CustomerDAO::create
CustomerDAO.java backend/src/dao/CustomerDAO.java
7 58
  • LONG METHOD
  • MAGIC NUMBERS
doGet com.legacybank.servlet.CustomerServlet::doGet
CustomerServlet.java backend/src/servlet/CustomerServlet.java
6 28
  • COMPLEX CONDITIONAL
doGet com.legacybank.servlet.LoanServlet::doGet
LoanServlet.java backend/src/servlet/LoanServlet.java
6 36 None detected
doPost com.legacybank.servlet.AccountServlet::doPost
AccountServlet.java backend/src/servlet/AccountServlet.java
6 38
  • DUPLICATE CODE
  • MAGIC NUMBERS
init com.legacybank.servlet.LoanServlet::init
LoanServlet.java backend/src/servlet/LoanServlet.java
5 26
  • DEEP NESTING
  • COMPLEX CONDITIONAL
init com.legacybank.servlet.AccountServlet::init
AccountServlet.java backend/src/servlet/AccountServlet.java
5 26
  • DEEP NESTING
  • SHOTGUN SURGERY

Most Common Code Smells

Frequently occurring code quality issues across the codebase.

Code Smell Type Occurrences Affected Files Recommendation
DATA CLASS 10 10 Review and refactor as part of modernization effort
TOO MANY METHODS 9 9 Review and refactor as part of modernization effort
MAGIC NUMBERS 8 8 Review and refactor as part of modernization effort
OTHER 8 8 Review and refactor as part of modernization effort
DUPLICATE CODE 6 6 Review and refactor as part of modernization effort
COMPLEX CONDITIONAL 4 4 Review and refactor as part of modernization effort
DEEP NESTING 4 4 Review and refactor as part of modernization effort
LONG PARAMETER LIST 3 3 Review and refactor as part of modernization effort
LONG METHOD 3 3 Review and refactor as part of modernization effort
SHOTGUN SURGERY 1 1 Review and refactor as part of modernization effort

Scheduled Jobs and Batch Processes JSON

Total Jobs 17
Trigger Types 3
Script Files 17

Trigger Types Found: event-driven, manual, scheduled

Job Name Source File Trigger Purpose Input Resources Output Resources
capture_query_log.sh capture_query_log.sh manual Runs a banking simulation against a Dockerized Oracle database and scrapes the executed SQL queries from the database cache to create an analysis log.
  • simulate_banking_operations.sql
  • Oracle Database (Docker container)
  • v$sql (Oracle System View)
  • query_log.sql
Dependencies: docker-compose, sqlplus, simulate_banking_operations.sql
check_all_tables.sh check_all_tables.sh manual Connects to the Oracle database to print sample records, row counts, and ID ranges for all major banking tables (branches, employees, customers, accounts, transactions, loans, cards, payments) to the console for debugging purposes.
  • Oracle Database
  • Table: branches
  • Table: employees
  • Table: customers
  • Table: accounts
  • Table: transactions
  • Table: loans
  • Table: cards
  • Table: payments
  • Console Output (Standard Output)
Dependencies: sqlplus, Docker (optional), legacy-bank-oracle container
Daily Interest Calculation Batch Job daily_interest.sh Scheduled (Daily implied by header comments) Calculates daily interest for all banking accounts by invoking a database stored procedure and committing the results.
  • Oracle Database (Connection)
  • interest_calculation.calculate_daily_interest (Stored Procedure)
  • /var/log/legacybank/daily_interest.log
  • Oracle Database (Data Updates)
Dependencies: sqlplus (Oracle Client), Oracle Database Instance
End of Day Processing eod_processing.sh Scheduled (End of Day) Executes the nightly financial close process, including transaction finalization, balance reconciliation, and reporting.
  • Oracle Database (transactions table)
  • Oracle Database (accounts table)
  • Oracle Database (updated transaction statuses)
  • Oracle Database (updated account balances)
  • /var/log/legacybank/eod_processing.log
  • /var/log/legacybank/eod_summary_YYYYMMDD.txt
Dependencies: sqlplus, Oracle Database Instance
javac_wrapper_execution javac-wrapper.sh event-driven This process is triggered whenever a build system or JSP container invokes the 'javac' command. It wraps the standard compilation process to inject the 'rt.jar' dependency into the classpath to prevent 'CharSequence' resolution errors.
  • Java Source Files
  • rt.jar
  • JAVA_HOME environment variable
  • Compiled Java Bytecode (.class files)
Dependencies: /opt/java/openjdk/bin/javac, /usr/lib/jvm/java-8-openjdk-amd64/bin/javac
JBoss Startup Process run-jboss.sh manual Initializes the Java environment with specific legacy compatibility fixes, cleans JSP caches, and launches the JBoss application server.
  • /usr/lib/jvm/java-8-openjdk-amd64
  • /opt/jboss/server/default/lib/rt.jar
  • /opt/jboss/bin/javac
  • /opt/jboss/server/default/tmp
  • /opt/jboss/server/default/work
  • /opt/jboss/server/default/data
Dependencies: /opt/jboss/bin/run.sh
Monthly Statement Generation Batch Job statement_generation.sh scheduled Generates text-based monthly account statements for all active customers containing their address, account summary, and a list of transactions for the previous month.
  • Oracle Database
  • Table: accounts
  • Table: customers
  • Table: transactions
  • Directory: /var/statements/legacybank
  • Files: statement_{account_number}_{YYYYMM}.txt
  • Log: /var/log/legacybank/statement_generation.log
Dependencies: sqlplus, Oracle Database Connection, UTL_FILE package permissions
Oracle Database Initialization 01_init_schema.sh event-driven (container startup) Initializes the Oracle database by creating the 'legacybank' user, applying schema definitions (tables, constraints), compiling stored procedures, and loading sample data.
  • 01_tables.sql
  • 02_constraints.sql
  • 03_indexes.sql
  • 04_triggers.sql
  • 05_supplemental_logging.sql
  • account_management.pkg
  • transaction_processing.pkg
  • loan_processing.pkg
  • interest_calculation.pkg
  • reload_all_data.sql
  • Oracle User 'legacybank'
  • Database Tables (customers, accounts, transactions, loans)
  • Stored Procedures
  • Database Schema
Dependencies: Oracle Database Instance (XEPDB1), sqlplus utility, sysdba credentials
Oracle Database Setup 00_setup.sh Container Startup (Event-driven) Initializes the Legacy Banking Application schema by waiting for the database to stabilize and then executing the specific schema initialization script.
  • /opt/oracle/scripts/setup/init/01_init_schema.sh
  • Oracle Database Schema
Dependencies: /opt/oracle/scripts/setup/init/01_init_schema.sh, Oracle Database Service
prepare_for_spda.sh prepare_for_spda.sh manual Reorganizes legacy database source files into an SPDA-compatible folder structure by splitting monolithic SQL files and renaming packages.
  • ${SCRIPT_DIR}/procedures/*.pkg
  • ${SCRIPT_DIR}/schema/01_tables.sql
  • ${SCRIPT_DIR}/schema/04_triggers.sql
  • ${SCRIPT_DIR}/spda/LEGACYBANK/packages/*.sql
  • ${SCRIPT_DIR}/spda/LEGACYBANK/tables/*.sql
  • ${SCRIPT_DIR}/spda/LEGACYBANK/triggers/*.sql
Dependencies: bash, sed, grep, tr
rebuild_and_redeploy.sh rebuild_and_redeploy.sh manual Orchestrates the full rebuild and redeployment cycle for the legacy-bank application, including database procedure updates, Java compilation, and JBoss server restart/cache clearing.
  • backend/ source code
  • database/recompile_procedures.sh
  • docker/docker-compose.yml
  • dist/legacy-bank.war
  • http://localhost:8080/legacy-bank/
  • JBoss server logs
Dependencies: docker, docker-compose, ant, curl/wget/nc, database/recompile_procedures.sh
recompile_procedures.sh recompile_procedures.sh manual Iterates through a predefined list of Oracle stored procedure packages and a triggers file to recompile them in the target database.
  • database/procedures/account_management.pkg
  • database/procedures/transaction_processing.pkg
  • database/procedures/loan_processing.pkg
  • database/procedures/interest_calculation.pkg
  • database/schema/04_triggers.sql
  • Oracle Database (Stored Procedures)
  • Oracle Database (Triggers)
Dependencies: sqlplus, docker, legacy-bank-oracle container
reload_all_data.sh reload_all_data.sh manual Clears existing database data and reloads fresh sample data by executing an external SQL script.
  • database/data/reload_all_data.sql
  • User Input (Credentials)
  • Oracle Database (legacy-bank-oracle)
Dependencies: docker, sqlplus, reload_all_data.sql
show_test_ids.sh show_test_ids.sh manual Displays test data entities (Branches, Employees, Customers, Accounts, Loans, Cards) either from static text or a live Oracle database to assist with testing.
  • Oracle Database
  • Environment Variables (ORACLE_USER, ORACLE_PASSWORD, ORACLE_HOST, ORACLE_PORT, ORACLE_SERVICE)
  • Console Output (Formatted Text Tables)
Dependencies: bash, sqlplus
test_stored_procedures.sh test_stored_procedures.sh manual Executes the `test_stored_procedures.sql` script via `sqlplus` to validate the functionality of database stored procedures.
  • test_stored_procedures.sql
  • Oracle Database (XEPDB1)
  • Console Standard Output
Dependencies: sqlplus, test_stored_procedures.sql
validate_all.sh validate_all.sh manual Runs the complete suite of database validation checks and stored procedure tests against a specified database connection.
  • Oracle Database (via connection string)
  • validate_database.sh
  • test_stored_procedures.sh
  • Console Output (Validation Report)
Dependencies: validate_database.sh, test_stored_procedures.sh
validate_database.sh validate_database.sh manual Validates database connectivity, schema object existence (tables, procedures, sequences, triggers), and data population.
  • Oracle Database
  • Connection String Argument
  • Console Validation Report
  • Exit Code
Dependencies: sqlplus, Oracle Database Instance

Module Coupling Analysis JSON

Total Modules 3
Coupling Relationships 2
Highest Coupling 32
Module Depth 2

Interpretation: High reference counts indicate tightly coupled modules (candidates for single services). Low reference counts indicate loosely coupled modules (candidates for easy separation).

From Module To Module Reference Count Coupling Level
backend/src com.legacybank 32 Very High
backend/web com.legacybank 23 Very High

Coupling Level Guide:

UI Technology Deep-Dive Analysis JSON

JSP Files: 20 | Total Scriptlets: 299 | Avg Scriptlets/File: 14.9 | High Debt Files: 18

⚠️ High Technical Debt Detected! 18 files have more than 10 scriptlet blocks. Consider refactoring to modern UI patterns (JSP tags, JSF components, or React/Vue).

No UI frameworks detected in configuration files.

Top JSP Files by Scriptlet Count (Technical Debt Hotspots)

File Path Scriptlets Expressions Declarations Total Blocks Debt Level
transaction_form.jsp backend/web/jsp/transaction_form.jsp
28 50 0 78 Very High
branch_portal.jsp backend/web/jsp/branch_portal.jsp
50 27 0 77 Very High
customer_portal.jsp backend/web/jsp/customer_portal.jsp
49 21 0 70 Very High
loan_details.jsp backend/web/jsp/loan_details.jsp
29 10 0 39 Very High
customer_form.jsp backend/web/jsp/customer_form.jsp
3 26 0 29 Very High
audit_log_list.jsp backend/web/jsp/audit_log_list.jsp
18 10 0 28 Very High
employee_portal.jsp backend/web/jsp/employee_portal.jsp
12 15 0 27 Very High
transaction_history.jsp backend/web/jsp/transaction_history.jsp
9 17 0 26 Very High
account_list.jsp backend/web/jsp/account_list.jsp
11 14 0 25 Very High
loan_form.jsp backend/web/jsp/loan_form.jsp
9 15 0 24 Very High

UI Modernization Insights

Database Stored Procedures & Triggers JSON

Stored Procedures 0
Triggers 9
Low Complexity 5
Medium Complexity 4
High Complexity 0

trg_customers_update Trigger

Path: database/schema/04_triggers.sql

Complexity: LOW (Consists of a single assignment statement.)

Lines: 6

Purpose: Updates the last_updated timestamp on the customers table whenever a row is updated.

trg_customers_audit Trigger

Path: database/schema/04_triggers.sql

Complexity: MEDIUM (Handles multiple event types (INSERT/UPDATE/DELETE) with string concatenation and conditional logic.)

Lines: 28

Purpose: Audits INSERT, UPDATE, and DELETE operations on the customers table by writing details to the audit_logs table.

trg_transactions_balance Trigger

Path: database/schema/04_triggers.sql

Complexity: MEDIUM (Contains conditional logic based on transaction type and performs updates on a related table.)

Lines: 21

Purpose: Updates the corresponding account balance and activity date in the accounts table whenever a new transaction is inserted.

trg_accounts_audit Trigger

Path: database/schema/04_triggers.sql

Complexity: LOW (Performs a single conditional insert operation.)

Lines: 10

Purpose: Audits changes to account balance or status by inserting a record into the audit_logs table.

trg_loans_approval Trigger

Path: database/schema/04_triggers.sql

Complexity: MEDIUM (Includes a SELECT query, validation logic with error raising, and date calculations.)

Lines: 19

Purpose: Validates that a customer has a verified KYC status before a loan can be approved and sets approval/maturity dates.

trg_loan_payments_balance Trigger

Path: database/schema/04_triggers.sql

Complexity: MEDIUM (Updates multiple fields and checks conditions for loan payoff status.)

Lines: 13

Purpose: Updates the remaining loan balance when a payment is made and marks the loan as paid off if the balance reaches zero.

trg_cards_expiration Trigger

Path: database/schema/04_triggers.sql

Complexity: LOW (Simple conditional check and assignment.)

Lines: 7

Purpose: Checks if a card's expiration date is in the past during insert or update and sets the status to EXPIRED if true.

trg_transactions_audit Trigger

Path: database/schema/04_triggers.sql

Complexity: LOW (Performs a single conditional insert operation.)

Lines: 10

Purpose: Audits changes to transaction status by recording the old and new values in the audit_logs table.

trg_accounts_balance_check Trigger

Path: database/schema/04_triggers.sql

Complexity: LOW (Simple validation check raising an error.)

Lines: 7

Purpose: Prevents checking or savings accounts from having a negative balance by raising an application error.

Database Interactions JSON

Path Mechanism Description Code Example
database/schema/01_tables.sql DDL The file consists entirely of SQL Data Definition Language (DDL) statements designed to initialize the database structure. It creates tables with specific columns, data types, and default values. It establishes relationships between these tables using Foreign Key constraints and enforces data validity using Check and Unique constraints. Additionally, it creates Sequences to handle auto-incrementing primary keys for every table defined. 
CREATE TABLE customers (
    customer_id NUMBER(10) PRIMARY KEY,
    first_name VARCHAR2(50) NOT NULL,
    last_name VARCHAR2(50) NOT NULL,
    ssn VARCHAR2(11) NOT NULL CONSTRAINT uk_customer_ssn UNIQUE,
    date_of_birth DATE NOT NULL,
database/schema/03_indexes.sql DDL The file interacts with the database via Data Definition Language (DDL) statements to modify the physical schema structure. It creates indexes on existing tables to optimize query performance. There is no application-layer code (like Java or Python); it is a direct SQL script intended for database administration or migration tools. 
CREATE INDEX idx_customers_name ON customers(last_name, first_name);
CREATE INDEX idx_customers_email ON customers(email);
CREATE INDEX idx_customers_kyc ON customers(kyc_status, kyc_verified_date);
database/schema/05_supplemental_logging.sql DDL The code utilizes Oracle-specific Data Definition Language (DDL) to modify the logging attributes of existing tables. It does not perform data manipulation or retrieval, but rather executes administrative commands (`ALTER TABLE ... ADD SUPPLEMENTAL LOG DATA`) to configure the database engine for Change Data Capture (CDC). 
ALTER TABLE customers ADD SUPPLEMENTAL LOG DATA (PRIMARY KEY) COLUMNS;
ALTER TABLE accounts ADD SUPPLEMENTAL LOG DATA (FOREIGN KEY) COLUMNS;
ALTER TABLE transactions ADD SUPPLEMENTAL LOG DATA (ALL) COLUMNS;
database/schema/02_constraints.sql DDL The file interacts with the database using Data Definition Language (DDL) to modify the schema structure. It specifically uses `ALTER TABLE` commands to inject `CHECK` constraints that validate data integrity upon insertion or update. 
ALTER TABLE customers ADD CONSTRAINT chk_email_format 
    CHECK (email IS NULL OR email LIKE '%@%.%');
ALTER TABLE transactions ADD CONSTRAINT chk_transaction_amount
    CHECK (amount > 0);
database/init/README.md DDL Database integration is achieved through shell scripts (`.sh`) that invoke the Oracle `sqlplus` CLI tool to execute raw SQL files. These scripts handle the full lifecycle of schema creation, including user management, object definition (tables, constraints, triggers), and initial data population. 
sqlplus legacybank/password@${ORACLE_SID} @database/schema/01_tables.sql
database/test_audit_logs.sql DML The file interacts with the database purely through SQL Data Manipulation Language (DML) scripts. It executes direct UPDATE statements against the 'customers' and 'accounts' tables. The script relies on the database's internal trigger mechanisms (mentioned in comments as 'trg_customers_audit' and 'trg_accounts_audit') to perform the actual auditing logic, although those triggers are not defined in this file. It uses explicit transaction management. 
UPDATE customers 
SET kyc_status = CASE 
    WHEN kyc_status = 'VERIFIED' THEN 'PENDING'
    ELSE 'VERIFIED'
END,
last_updated = SYSDATE
com.legacybank.servlet.AccountServlet EJB The servlet primarily delegates database interactions to the AccountServiceLocal EJB. However, it contains a fallback mechanism in the init() method that directly interacts with the container's JNDI registry to look up a JDBC DataSource ('java:LegacyBankDS') and inject it into a manually instantiated bean instance. 
DataSource ds = (DataSource) ctx.lookup("java:LegacyBankDS");
com.legacybank.ejb.AccountServiceBean bean = new com.legacybank.ejb.AccountServiceBean();
bean.setDataSource(ds);
com.legacybank.servlet.LoanServlet EJB The servlet primarily interacts with the database through the `LoanServiceLocal` EJB. However, in the `init` method's fallback logic, it directly looks up a JDBC `DataSource` via JNDI to manually configure the service bean, indicating a direct dependency on a configured database resource. 
DataSource ds = (DataSource) ctx.lookup("java:LegacyBankDS");
com.legacybank.ejb.LoanServiceBean bean = new com.legacybank.ejb.LoanServiceBean();
bean.setDataSource(ds);
com.legacybank.servlet.TransactionServlet EJB The servlet primarily delegates database persistence logic to an EJB (TransactionServiceLocal). However, in the init() method, there is explicit code to look up a JDBC DataSource via JNDI ('java:LegacyBankDS') and inject it into a bean if the EJB lookup fails. This indicates a hybrid approach where the servlet can manually wire up database connectivity. 
DataSource ds = (DataSource) ctx.lookup("java:LegacyBankDS");
com.legacybank.ejb.TransactionServiceBean bean = new com.legacybank.ejb.TransactionServiceBean();
bean.setDataSource(ds);
README.md JDBC The application interacts with an Oracle 21c XE database using direct JDBC connections obtained via JNDI lookups (java:LegacyBankDS). It relies heavily on raw SQL for complex joins and CallableStatements for executing PL/SQL stored procedures to handle business logic like interest calculations and account creation. Batch operations are handled via shell scripts invoking SQL*Plus. 
// Call stored procedure - demonstrates tight coupling
String sql = "{call account_management.create_account(?, ?, ?, ?, ?, ?, ?, ?, ?)}";
stmt = conn.prepareCall(sql);
stmt.setLong(1, customerId);
stmt.setLong(2, branchId);
stmt.execute();
docker/Dockerfile.jboss JDBC The Dockerfile enables database connectivity by downloading the Oracle JDBC driver (`ojdbc6.jar`) and installing it into the JBoss server's global library directory. It further integrates the database by copying a specific `datasource.xml` configuration file into the JBoss deployment folder, which registers the datasource with the application server's JNDI registry. 
RUN echo "Downloading Oracle JDBC driver..." && \
    mkdir -p /opt/jboss/server/default/lib && \
    curl -L ... -o /opt/jboss/server/default/lib/ojdbc6.jar ...

# Configure datasource
COPY --chown=jboss:jboss docker/datasource.xml /opt/jboss/server/default/deploy/legacy-bank-ds.xml
docker/README-JBOSS-SETUP.md JDBC The document provides instructions for installing the Oracle JDBC driver (`ojdbc6.jar`) into the JBoss server's library path. It explains that the driver must be downloaded manually from Oracle due to licensing restrictions and placed in the specific `docker/` directory or mounted as a volume to enable database connectivity. 
volumes:
  - ./ojdbc6.jar:/opt/jboss/server/default/lib/ojdbc6.jar
com.legacybank.dao.AccountDAO JDBC The file uses raw JDBC (Java Database Connectivity) to interact with the database. It manually manages Connections, PreparedStatements, and ResultSets. SQL queries are embedded directly as strings within the Java code. 
conn = dataSource.getConnection();
String sql = "SELECT ... FROM accounts a WHERE a.account_id = ?";
stmt = conn.prepareStatement(sql);
stmt.setLong(1, accountId);
rs = stmt.executeQuery();
com.legacybank.dao.CustomerDAO JDBC The file uses standard Java JDBC (Java Database Connectivity) to interact with the database. It manually manages `Connection`, `PreparedStatement`, and `ResultSet` objects. It uses a `DataSource` for connection pooling. 
conn = dataSource.getConnection();
String sql = "SELECT ... FROM customers WHERE customer_id = ?";
stmt = conn.prepareStatement(sql);
stmt.setLong(1, customerId);
rs = stmt.executeQuery();
com.legacybank.dao.TransactionDAO JDBC The file uses raw JDBC (Java Database Connectivity) to interact with the database. It manually manages Connections, PreparedStatements, and ResultSets. It constructs SQL strings directly within the Java code and handles the mapping of database rows to Java objects manually. 
conn = dataSource.getConnection();
String sql = "SELECT ... FROM transactions WHERE transaction_id = ?";
stmt = conn.prepareStatement(sql);
stmt.setLong(1, transactionId);
rs = stmt.executeQuery();
com.legacybank.servlet.CustomerServlet JDBC The servlet uses JNDI to look up a DataSource ('java:LegacyBankDS') and injects it into a CustomerDAO helper class. The servlet itself does not execute SQL but delegates all persistence operations (create, read, update) to the DAO which holds the DataSource connection. 
InitialContext ctx = new InitialContext();
DataSource ds = (DataSource) ctx.lookup("java:LegacyBankDS");
customerDAO = new CustomerDAO();
customerDAO.setDataSource(ds);
docker/docker-compose.yml OTHER The file configures an Oracle Database container instance and defines the connection parameters (Host, Port, SID, PDB, User, Password) passed to the application server. It also executes a direct SQL command via the container health check mechanism. 
test: ["CMD-SHELL", "sqlplus -s sys/REDACTED@localhost:1521/XEPDB1 as sysdba <<< 'SELECT 1 FROM DUAL;' || exit 1"]
docker/Dockerfile.oracle OTHER This file does not connect to a database as a client; rather, it defines the database server environment itself. It integrates database initialization by copying schema, procedure, and data scripts into the Oracle container's startup directories. It configures the database instance parameters via environment variables. 
ENV ORACLE_SID=XE
ENV ORACLE_PDB=XEPDB1
ENV ORACLE_PWD=Oracle123
COPY database/schema/ /opt/oracle/scripts/setup/schema/
docker/README-ORACLE-SETUP.md OTHER The file documents the infrastructure setup and connection parameters for Oracle Database (XE and Enterprise editions), defining connection strings, SIDs, and PDBs used by the application's Docker containers. 
environment:
  - ORACLE_SID=ORCL
  - ORACLE_PDB=LEGACYPDB
database/simulate_banking_operations.sql SQL The file is a standalone SQL script containing Direct Manipulation Language (DML) and Data Query Language (DQL) statements. It interacts directly with an Oracle database to simulate banking operations. The script performs extensive read operations involving joins and aggregations, and simulates write operations within a transaction that is ultimately rolled back. 
SELECT account_id, balance FROM accounts WHERE account_id = 1;
UPDATE accounts SET balance = balance + 500.00, last_activity_date = SYSDATE
WHERE account_id = 1;
ROLLBACK;
database/query_log.sql SQL The file represents direct SQL interaction with an Oracle database. It contains a mix of DQL (Data Query Language) for retrieving customer and account data, and DML (Data Manipulation Language) for processing transactions and updating balances. The presence of bind variables (e.g., :B1) suggests the original application used JDBC or a similar driver with prepared statements. The schema is identified as 'LEGACYBANK'. 
SELECT a.*, t.transaction_id, t.amount, t.transaction_type 
FROM accounts a 
JOIN transactions t ON a.account_id = t.account_id 
WHERE a.account_id = 2;
database/data/README.md SQL Database integration is achieved through direct execution of SQL scripts using the Oracle `sqlplus` command-line tool. The scripts perform bulk Data Manipulation Language (DML) operations, specifically deleting existing rows and inserting new sample data, as well as executing stored procedures to generate complex related data. 
sqlplus legacybank/REDACTED@localhost:1521/XEPDB1 @database/data/reload_all_data.sql
database/validation/cleanup_test_customer.sql SQL The code interacts with the database via a raw PL/SQL anonymous block intended for execution in a client like SQL*Plus. It utilizes procedural SQL features including variable declaration, cursor loops, exception handling, and dynamic SQL execution. The integration performs deep administrative cleanup tasks involving complex read and write operations across the schema. 
BEGIN
    SELECT customer_id INTO v_test_customer_id 
    FROM customers 
    WHERE ssn = '999-99-9999';
    DELETE FROM customers WHERE customer_id = v_test_customer_id;
database/data/reload_all_data.sql SQL The file is a standalone Oracle PL/SQL script that interacts directly with the database engine. It performs a combination of DDL (Data Definition Language) to manage sequences and constraints, and DML (Data Manipulation Language) to delete and insert data. It leverages Oracle-specific features such as `EXECUTE IMMEDIATE` for dynamic SQL, `RETURNING ... INTO` clauses for capturing generated IDs, and `DBMS_OUTPUT` for logging progress. The script also integrates with existing database packages (`account_management`, `transaction_processing`, `loan_processing`) to insert data through the application's business logic layer rather than raw inserts for complex entities. 
INSERT INTO branches (branch_id, branch_code, branch_name, address_line1...)
VALUES (seq_branch_id.NEXTVAL, 'NYC001', 'Manhattan Main Branch'...)
RETURNING branch_id INTO v_branch_nyc;

COMMIT;
database/validation/test_stored_procedures.sql SQL The file is a PL/SQL script that acts as a test harness for the database. It interacts with the database by executing anonymous blocks that call existing stored procedures within packages (e.g., 'account_management', 'transaction_processing'). It performs direct DML operations (INSERT, SELECT, DELETE) to stage test data and clean it up. It also performs administrative tasks by disabling and enabling triggers via EXECUTE IMMEDIATE statements. 
account_management.create_account(
    p_customer_id => v_customer_id,
    p_branch_id => v_branch_id,
    p_account_type => 'CHECKING',
    p_initial_deposit => 1000.00,
    p_account_id => :v_account_id,
database/validation/README.md SQL Database integration is achieved through the execution of Shell scripts that invoke the Oracle SQL*Plus command-line tool. These scripts pass connection strings and SQL files to the database engine to perform schema validation, data counting, and stored procedure execution tests. 
sqlplus legacybank/REDACTED@localhost/XEPDB1 @test_stored_procedures.sql
database/procedures/account_management.pkg STORED-PROCEDURE The file is a PL/SQL package (Specification and Body) that runs directly inside the Oracle database, executing SQL statements against local tables to manage data. 
INSERT INTO accounts (
    account_id, customer_id, branch_id, account_number,
    account_type, balance, interest_rate, opened_date
) VALUES (
    seq_account_id.CURRVAL, p_customer_id, p_branch_id, v_account_num,
    p_account_type, p_initial_deposit, 
    NVL(p_interest_rate, 0.0000), SYSDATE
);
database/procedures/interest_calculation.pkg STORED-PROCEDURE The code is a native Oracle PL/SQL package that executes directly within the database engine. It performs direct SQL operations including selecting account details, inserting transaction records, and logging audits. It utilizes cursors for row-by-row processing and manages transaction consistency explicitly. 
SELECT account_type, balance, interest_rate... INTO ... FROM accounts WHERE account_id = p_account_id; INSERT INTO transactions (...) VALUES (...);
database/procedures/loan_processing.pkg STORED-PROCEDURE The code is a native Oracle PL/SQL package that executes directly within the database engine. It performs direct Data Manipulation Language (DML) and Data Query Language (DQL) operations on the underlying tables without an intermediate ORM or driver layer. 
INSERT INTO loans (
    loan_id, customer_id, branch_id, loan_number, ...
) VALUES (
    seq_loan_id.CURRVAL, p_customer_id, p_branch_id, v_loan_number, ...
);

COMMIT;
database/procedures/transaction_processing.pkg STORED-PROCEDURE This file represents a server-side Oracle PL/SQL package that directly interacts with the database engine. It executes Data Manipulation Language (DML) operations to insert transaction records and update balances (implied via triggers or subsequent logic), and Data Query Language (DQL) to validate account states and aggregate history. 
SELECT account_status, balance INTO v_account_status, v_current_balance
FROM accounts
WHERE account_id = p_account_id;

-- ... validation logic ...

INSERT INTO transactions (
    transaction_id, account_id, transaction_type, ...
) VALUES (
    seq_transaction_id.NEXTVAL, p_account_id, 'DEPOSIT', ...
);

COMMIT;
com.legacybank.ejb.AccountServiceBean STORED-PROCEDURE The application interacts with the database exclusively through JDBC `CallableStatement` objects invoking stored procedures defined in an `account_management` package. It uses a DataSource resource mapped to `java:LegacyBankDS`. 
String sql = "{call account_management.create_account(?, ?, ?, ?, ?, ?, ?, ?, ?)}";
stmt = conn.prepareCall(sql);
stmt.setLong(1, customerId);
com.legacybank.ejb.LoanServiceBean STORED-PROCEDURE The class interacts with an Oracle-style database via a DataSource. It primarily uses Stored Procedures (via CallableStatement) for business logic (creation, approval) and complex data retrieval. It also uses direct SQL (via PreparedStatement) for simple data fetching. 
String sql = "{call loan_processing.create_loan_application(?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?)}";
stmt = conn.prepareCall(sql);
stmt.setLong(1, customerId);
com.legacybank.ejb.TransactionServiceBean STORED-PROCEDURE The application integrates with the database primarily through Stored Procedures invoked via JDBC CallableStatements. It uses a DataSource resource mapped to 'java:LegacyBankDS'. 
String sql = "{call transaction_processing.process_deposit(?, ?, ?, ?, ?, ?, ?, ?, ?)}";
stmt = conn.prepareCall(sql);
stmt.setLong(1, accountId);
...
database/schema/04_triggers.sql TRIGGER The code integrates directly into the database using Oracle PL/SQL triggers to execute business logic automatically in response to DML events. It performs cross-table updates (e.g., updating accounts from transactions) and enforces data integrity rules. 
CREATE OR REPLACE TRIGGER trg_customers_update
BEFORE UPDATE ON customers
FOR EACH ROW
BEGIN
    :NEW.last_updated := SYSDATE;
END;

Integration Points JSON

AccountServiceLocal

Namespace: com.legacybank.ejb.AccountServiceLocal

Mechanism: OTHER

Direction: BIDIRECTIONAL

Path/Topic: N/A

Description: EJB Local Interface definition used for internal service-to-service communication within the application container.

EJB Local Interface

Namespace: com.legacybank.ejb.LoanServiceLocal

Mechanism: OTHER

Direction: BIDIRECTIONAL

Path/Topic: N/A

Description: Defines the local business interface for an Enterprise Java Bean.

AccountServlet

Namespace: com.legacybank.servlet.AccountServlet

Mechanism: REST

Direction: CONSUMER

Path/Topic: unknown (defined in web.xml)

Description: Servlet endpoint handling HTTP requests for account operations.

CustomerServlet

Namespace: com.legacybank.servlet.CustomerServlet

Mechanism: REST

Direction: BOTH

Path/Topic: unknown

Description: Handles HTTP requests for customer management (Servlet acting as a web endpoint).

LoanServlet HTTP Endpoint

Namespace: com.legacybank.servlet.LoanServlet

Mechanism: REST

Direction: CONSUMER

Path/Topic: Mapped via web.xml (implied)

Description: Standard Java Servlet endpoint handling HTTP requests for loan management.

TransactionServlet

Namespace: com.legacybank.servlet.TransactionServlet

Mechanism: REST

Direction: BIDIRECTIONAL

Path/Topic: /TransactionServlet (inferred)

Description: HTTP Servlet entry point handling transaction requests.

TransactionServiceLocal

Namespace: com.legacybank.servlet.TransactionServlet

Mechanism: OTHER

Direction: CONSUMER

Path/Topic: legacy-bank/TransactionServiceLocal

Description: JNDI Lookup for EJB Service

BankingService

Namespace: com.legacybank.soap.BankingServiceEndpoint

Mechanism: SOAP

Direction: BIDIRECTIONAL

Path/Topic: http://legacybank.com/soap

Description: JAX-WS SOAP Service Endpoint exposing banking operations