CBMS Microservices — Project Direction¶
Cooperative Bank Management System Internal Document — Team Discussion Date: 2026-06-10
1. Project Objective¶
Migrate the CBMS cooperative banking system from the legacy Oracle-based monolithic application to a modern microservices architecture using Spring Boot, React.js, and PostgreSQL. The goal is a maintainable, scalable, and independently deployable system aligned with current enterprise standards.
2. Team Structure and Responsibilities¶
| Role | Responsibility |
|---|---|
| Domain Experts | Screen-level business logic, SQL validation, Flyway migration scripts, AI-assisted screen implementation based on legacy references |
| Java Developer | Git repository management, Spring Boot service integration, React wiring, BackendBusinessProcess.java, Docker Compose |
| Team Lead | Architecture decisions, CI/CD pipeline, code standards, technical review, inter-service integration |
| Manager | Task allocation, progress tracking, escalation, cross-team coordination |
3. Development Approach¶
3.1 AI-Assisted Development¶
Each domain expert works with AI on their assigned screens using the following structured approach:
Step 1 — Understand "Please explain... Do not make code changes"
Step 2 — Validate Review the explanation against domain knowledge
Step 3 — Implement "Please make the changes"
Step 4 — Verify Check using Docker logs and screen testing
This approach ensures domain experts retain control over what gets implemented while leveraging AI for the technical execution.
3.2 Legacy-First Reference¶
All screen implementations must refer to:
- Legacy screenshots for UI layout
- Legacy .java UI and OB files for dropdown values and validations
- Legacy SQL dump for table structures and function signatures
3.3 Database Strategy¶
- All microservices share a single PostgreSQL database (
neocoredb) - Business logic remains in PostgreSQL functions — Java code acts as a typed wrapper
- Database objects are version-controlled via Flyway migration scripts
- All 640 functions, 69 procedures, 444 views from the demo database are already migrated to Flyway V7 in
common-service
4. Technology Stack¶
| Layer | Technology | Purpose |
|---|---|---|
| Frontend | React.js (showcase-app) | User interface |
| Backend | Spring Boot (Java 17) | REST API microservices |
| Database | PostgreSQL 13 | Data storage and business logic |
| Containerization | Docker Compose | Local and server deployment |
| Version Control | Git | Source code management |
| CI/CD | To be set up by Team Lead | Automated build and deployment |
5. Microservices Inventory¶
| Service | Domain | Status |
|---|---|---|
customer-service |
Customer master, KYC, individual/corporate | In Progress |
deposit-service |
Term deposit, recurring, thrift, daily deposit | In Progress |
transaction-service |
Cash and transfer transactions | In Progress |
product-service |
Product configuration, interest rates | In Progress |
generalledger-service |
GL heads, balance sheet, day book | In Progress |
system-setup-service |
Branch, user, screen, holiday, system config | In Progress |
periodicactivity-service |
Interest calculation, inoperative charges | In Progress |
share-service |
Share accounts, MDS chit fund | Pending |
bankandbranch-service |
Bank master, branch master | Pending |
common-service |
Shared utilities, cross-domain functions | Done — Flyway V7 |
termloan-service |
Term loan, KCC, ADV/OD | Pending |
operativeaccount-service |
SB, CA, OD accounts | Pending |
suspenseaccount-service |
Suspense interest and accounts | Pending |
gdsapplication-service |
Gold, security, GDS applications | Pending |
payroll-service |
Staff payroll, PF, leave | Pending |
6. Project Phases¶
Phase 0 — Foundation¶
Target: Immediate
Establish the shared working environment so all team members contribute to a single codebase.
| Task | Owner | Priority |
|---|---|---|
| Set up Git repository with full project structure | Java Developer | Critical |
| Collect all individual local work and push to Git | Java Developer | Critical |
| Confirm Flyway version registry — assign version ranges per service | Team Lead | Critical |
Confirm naming: commonbackendbusinessprocess-service vs domain-split (5 services) |
Team Lead | High |
| Verify Docker Compose brings all services up cleanly | Java Developer | High |
| Share this document and Flyway version registry with all team members | Manager | High |
Flyway Version Registry — Version ranges assigned per service to prevent conflicts:
| Service | Versions Used | Next Available |
|---|---|---|
| common-service | V1–V7 | V8 onwards |
| deposit-service | V1–V19 | V20 onwards |
| customer-service | V1–V9 | V10 onwards |
| transaction-service | V1–V7 | V8 onwards |
| generalledger-service | V1–V6 | V7 onwards |
| product-service | V1–V7 | V8 onwards |
| periodicactivity-service | V1–V5 | V6 onwards |
| share-service | V1 | V2 onwards |
| bankandbranch-service | V1 | V2 onwards |
| system-setup-service | V1 | V2 onwards |
| termloan-service | V1 | V2 onwards |
| operativeaccount-service | V1 | V2 onwards |
| suspenseaccount-service | V1 | V2 onwards |
| gdsapplication-service | V1 | V2 onwards |
| payroll-service | V1 | V2 onwards |
Rule: Before creating any new Flyway migration file, check the Git repository for the highest existing version number in that service. Never use the same version number as another team member.
Phase 1 — Screen Implementation¶
Target: 2–3 Weeks
Each domain expert completes their assigned screens. Java developer integrates completed work into Git continuously — do not wait until all screens are done.
Currently In Progress¶
| Module | Screen | Assigned To |
|---|---|---|
| Deposits | TimeDeposits — New TD | — |
| Deposits | Cash and Transfer Transactions | — |
| Deposits | Nominee, Joint Account Holder, Authorized Signatory | — |
| Deposits | Auto Renewal, Sub Account Info | — |
| Customer | Individual — Personal Details, KYC, Photo & Signature | — |
| General Ledger | Major/Sub Head | — |
| Product Management | Liability Portfolio | — |
| System Setup | Interest Rate Group and Calculation | — |
| Periodic Activity | Interest Rate (moved from System Setup) | — |
Integration Tasks — Java Developer¶
| Task | Notes |
|---|---|
| Wire completed React screens to service APIs | As each screen is handed over |
| Complete missing BackendBusinessProcess.java methods | From SQL function signatures in the dump |
| Seed lookup_master data for all dropdowns | Coordinate with domain expert for lookup keys |
| Resolve Flyway version conflicts | Check before each merge |
| Maintain Docker Compose — all services operational | After every merge |
Architecture Tasks — Team Lead¶
| Task | Notes |
|---|---|
| Define Git branching strategy | Feature branches or single develop branch |
| Set up CI/CD pipeline | Push → Build → Deploy |
| Review code standards and enforce consistency | BackendBusinessProcess pattern, API response format |
| Server environment setup | Development and staging |
Phase 1 Completion Criteria¶
- [ ] All assigned screens functional end-to-end
- [ ] All screens integrated with their respective service APIs
- [ ] All dropdowns populated from database
- [ ] Docker Compose starts all services without errors
- [ ] No Flyway checksum conflicts
Phase 2 — Remaining Modules¶
Target: 1–2 Months
Implement modules not yet started. These require domain expert assignment.
| Module | Screens |
|---|---|
| Term Loan | Loan application, disbursement, repayment schedule, interest |
| Shares / MDS | Share account opening, MDS chit fund, dividend |
| Operative Accounts | Savings, Current, Overdraft account operations |
| Periodic Activity | Day-end processing, inoperative charges, interest posting |
| Reports | Transaction reports, balance sheet, day book, trial balance |
| System Setup | Holiday master, branch configuration, user and role management |
Database Completeness — Phase 2 Requirement¶
The following production schemas are not yet covered by Flyway migrations. Schema-only dumps are required from the DBA:
| Schema | Contents | Priority |
|---|---|---|
pkgdayend |
Day-end batch processing | High |
pkgtrans |
Transaction processing package | High |
pkg_fin_rpt |
Financial reporting | High |
pkgreports / pkggenreports |
Report execution | Medium |
pkg_app_valdate |
Application validation | Medium |
pkg_gn_pbk |
Passbook generation | Medium |
pkgschedule |
Scheduled processing | Medium |
pkg_app_exec |
Application execution | Medium |
oracle |
Oracle compatibility functions | Confirm if orafce extension installed |
Action for Team Lead / DBA: Run
SELECT * FROM pg_extension WHERE extname = 'orafce';on the target server. Iforafceis installed, theoracle,dbms_*, andplv*schemas are handled automatically — no dump needed for those.
Phase 3 — Production Preparation¶
Target: 2–4 Months
| Area | Tasks |
|---|---|
| Security | JWT authentication, RBAC per screen, encrypted credentials, HTTPS, audit logging |
| Data Migration | Strategy for migrating live bank data from Oracle/legacy to PostgreSQL |
| Performance | Load testing for day-end procedures, connection pool tuning, report query optimization |
| Operations | Monitoring and alerting, backup/recovery procedures, operational runbook |
| Compliance | RBI CBS compliance checklist, audit trail verification |
Phase 4 — Deployment¶
Target: 3–6 Months
| Task | Notes |
|---|---|
| Pilot branch selection | One branch runs new system in parallel with legacy |
| Parallel run period | Both systems active, outputs compared |
| Staff training | Domain experts lead — they know the screens |
| Data cutover | Legacy data migrated to new system |
| Legacy decommission | After validation period |
7. Standards — All Team Members Must Follow¶
Code Standards¶
| Standard | Rule |
|---|---|
| BackendBusinessProcess pattern | One class per service, JDBC wrappers only — no business logic in Java |
| Flyway naming | V{n}__{description}.sql — lowercase, underscores, descriptive |
| API response format | Consistent JSON structure across all services |
| React component structure | Follow existing pattern from customer-service screens |
Prompt Standards for AI-Assisted Work¶
When working with AI on any screen, always include: 1. Screen name and module path 2. Reference to legacy screenshot or Java UI file 3. Reference to SQL dump for table/function context 4. Explicit instruction: "Do not make code changes" for explanation requests 5. Explicit instruction: "Make changes only in showcase-app" when UI-only change
Git Workflow¶
| Step | Action |
|---|---|
| 1 | Before starting work — pull latest from Git |
| 2 | Complete a screen or feature |
| 3 | Share files with Java developer (folder / messaging) |
| 4 | Java developer reviews, resolves conflicts, commits and pushes |
| 5 | Verify in Docker after push |
8. What Is Already Delivered¶
| Deliverable | Details |
|---|---|
| BackendBusinessProcess.java | All 15 microservices — JDBC wrappers for all demo DB functions |
| Flyway V7 Migration | common-service — 640 functions, 69 procedures, 444 views, 1 trigger, 93 types |
| Architecture Decision Document | docs/Architecture_Decision_DB_Functions_vs_Java.md |
| Docker Compose | All services containerized |
| Deposit workflow screens | New TD, transaction, nominee, joint holder, authorized signatory |
| Customer screens | Individual, KYC, photo/signature |
| GL, Product, System Setup | Screens in progress |
9. Open Decisions — Requires Team Lead Input¶
| Decision | Options | Impact |
|---|---|---|
| Utility service naming | commonbackendbusinessprocess-service (single) vs 5 domain-split services |
Affects all team members — decide before Phase 1 merge |
| Git branching strategy | Feature branches vs single develop | Affects daily workflow |
orafce extension |
Installed or manual schemas | Affects Phase 2 database tasks |
| Production schema dumps | DBA access required | Blocks Phase 2 database completeness |
Internal document — Team Discussion CBMS Project · 2026-06-10