The Decomposition design pattern

package com.bank.service;

// Each service owns one business capability end to end.

// PaymentService: everything about payments
public class PaymentService {
    public void initiateTransfer(String fromId, String toId, java.math.BigDecimal amount) {
        // Handles transfer initiation, settlement, reversal
    }
}

// LoanService: everything about loans
public class LoanService {
    public void sanctionLoan(String customerId, java.math.BigDecimal principal) {
        // Handles sanction, EMI calculation, disbursement
    }
}

// NotificationService: everything about notifications
public class NotificationService {
    public void sendSms(String customerId, String message) {
        // Handles SMS, email, push
    }
}

Boundary is stable because business capabilities change slowly.
Ownership is clear: one team owns "payments" end to end.

WRONG: Split by technical layer (ControllerService, DAOService)
  -> Every feature spans every service. Distributed monolith.

package com.bank.lending.model;

import java.math.BigDecimal;

// In the Lending context, "Account" means a loan account.
public class LoanAccount {
    private String loanAccountId;
    private BigDecimal principal;
    private BigDecimal interestRate;
    private int tenureMonths;
    // This is NOT the same as a deposit account.
}

package com.bank.deposits.model;

import java.math.BigDecimal;

// In the Deposits context, "Account" means a savings/current account.
public class DepositAccount {
    private String accountId;
    private BigDecimal balance;
    private String accountType; // SAV, CUR
    // This is NOT the same as a loan account.
}

"Account" means different things in different contexts:
  Deposits: savings account with a balance
  Lending: loan account with principal and EMI
  Cards: credit card account with a limit

Each context has its own model. No shared "Account" class.

package com.bank.ledger;

import org.springframework.stereotype.Service;
import org.springframework.transaction.annotation.Transactional;
import java.math.BigDecimal;

@Service
public class LedgerService {

    @Transactional
    public void postEntry(String accountId, BigDecimal debit, BigDecimal credit) {
        // Debit and credit of a single ledger posting MUST be atomic.
        // Keep them in ONE service, ONE transaction.
        // Splitting them would force a Saga for something that should be simple.
    }
}

Rule: Keep strongly consistent operations in one service.
Accept Sagas only across boundaries where eventual consistency is fine.

Keep together: debit + credit of a single ledger posting
Split with Saga: debit Rajesh (Account Service) + credit Priya (Account Service)
  -> Two different accounts, two different aggregates, Saga is appropriate.

Combined decomposition:
  1. List business capabilities -> Account, Payment, Loan, Notification, Fraud
  2. Refine with DDD -> "Account" means deposit in Deposits context,
     loan in Lending context
  3. Transaction check -> debit+credit of one posting stays in one service
  4. Scalability check -> Fraud scoring extracted (10x peak scaling needed)

GOOD boundary:
  Payment Service changes only when payment logic changes.
  Talks to Account Service once per transfer.
  Can be deployed independently.

BAD boundary:
  PaymentController Service changes with every feature.
  Calls BusinessLogic Service and DAOService for everything.
  Must deploy with both. Distributed monolith.

package com.bank.antipattern;

// WRONG: Technical layer decomposition.
// Every feature spans all services.
public class WrongDecomposition {
    // api-gateway-service: routes
    // business-logic-service: rules
    // database-service: persistence
    // Result: distributed monolith.
}

// CORRECT: Business capability decomposition.
public class CorrectDecomposition {
    // payment-service: owns payment logic + payment DB
    // account-service: owns account logic + account DB
    // Each service is self-contained.
}