Design Patterns: Khi GoF Cứu Rỗi Một Hệ Thống Thanh Toán

Chào mừng bạn đến với thế giới của những hệ thống thanh toán lõi ngân hàng – nơi một dòng if-else tưởng chừng vô hại có thể trở thành cơn ác mộng bảo trì chỉ sau vài năm. Hôm nay, chúng ta sẽ mổ xẻ một câu chuyện hoàn toàn có thật (tôi đã chứng kiến ở vài ngân hàng) và cách các Design Patterns kinh điển của GoF đã “cứu rỗi” kiến trúc khỏi sự hỗn loạn.

Mở Đầu: Câu Chuyện Bùng Nổ Phương Thức Thanh Toán Tại X Bank

Hãy tưởng tượng bạn là kỹ sư phần mềm tại X Bank. Năm đầu tiên, mọi thứ thật đẹp. Ứng dụng chỉ hỗ trợ chuyển khoản nội bộ (T0 settlement). Class PaymentService gọn gàng 200 dòng, logic tính phí cứng: fee = 0. Ai cũng vui vẻ.

Năm thứ hai, đội ngũ kinh doanh mang về hợp đồng với VietQR. Lúc này, bạn bắt đầu thêm vào PaymentService những khối if-else đầu tiên:

if (paymentMethod.equals("INTERNAL")) {
    // Internal logic
} else if (paymentMethod.equals("VIETQR")) {
    // VietQR logic (cách tính phí 1% + 5k, validation QR code...)
}

Service phình lên 600 dòng. Không sao, vẫn quản lý được.

Năm thứ ba, NAPAS gia nhập cuộc chơi. Service vọt lên 1200 dòng. Số lượng else if tăng lên, mức độ lồng ghép sâu đến 8 cấp. Một bug nhỏ trong logic tính phí của VietQR có thể vô tình làm sập cả luồng chuyển khoản nội bộ.

Năm thứ tư, yêu cầu mới từ cấp trên: “Thêm phương thức thanh toán thứ 5 là SWIFT. Deadline: 2 tuần. Quan trọng nhất: Không được đụng vào code hiện tại của 4 phương thức kia để tránh rủi ro regression.”

Đây chính là khoảnh khắc bạn nhận ra nếu tiếp tục code theo kiểu “mì ăn liền”, hệ thống sẽ sụp đổ. Và đó cũng là lúc các Design Patterns bước lên vũ đài.

Trong bài viết này, chúng ta sẽ đi qua 6 pattern quan trọng nhất đã giải cứu X Bank, kèm theo code Java production-grade và những bài học xương máu về Trade-off.

1. Strategy Pattern: Định Mệnh Của Logic Tính Phí

Bài toán: Mỗi phương thức thanh toán có một cách tính phí khác nhau:

Internal: Miễn phí (0 VND).
VietQR: 1% số tiền + 5,000 VND.
NAPAS: 2% + 10,000 VND.
SWIFT: 50,000 VND cố định + phí ngân hàng trung gian.

Việc nhồi nhét tất cả công thức này vào một method calculateFee() với hàng tá switch-case là công thức đảm bảo cho “Merge Conflict” trong tương lai.

Giải pháp: Strategy Pattern cho phép chúng ta đóng gói thuật toán vào các class riêng biệt. PaymentProcessor (Context) chỉ cần biết nó đang dùng Strategy nào, không cần biết tính toán ra sao.

// Giao diện chiến lược
public interface FeeCalculationStrategy {
    Money calculateFee(Money amount, PaymentMethodType methodType);
}

// Chiến lược cho VietQR
public class VietQRFeeStrategy implements FeeCalculationStrategy {
    private static final BigDecimal RATE = BigDecimal.valueOf(0.01);
    private static final Money FIXED = Money.of(5000, "VND");

    @Override
    public Money calculateFee(Money amount, PaymentMethodType methodType) {
        return amount.multiply(RATE).add(FIXED);
    }
}

// Chiến lược cho SWIFT
public class SWIFTFeeStrategy implements FeeCalculationStrategy {
    private static final Money FIXED = Money.of(50000, "VND");
    
    @Override
    public Money calculateFee(Money amount, PaymentMethodType methodType) {
        return FIXED;
    }
}

Lợi ích: Khi thêm phương thức thứ 6 (ví dụ Crypto), bạn chỉ cần tạo class CryptoFeeStrategy, viết test cho nó, và hệ thống tự động hoạt động. Zero changes vào code hiện có.

Rule of Thumb: Nếu bạn có > 3 biến thể thuật toán hoặc logic thay đổi thường xuyên, hãy dùng Strategy. Nếu chỉ có 2-3 case đơn giản, if-else vẫn ổn.

2. Factory Pattern: Ẩn Giấu Sự Phức Tạp Khởi Tạo

Bài toán: Để chạy được một giao dịch SWIFT, bạn cần một đối tượng SWIFTPaymentProcessor. Nhưng Processor này cần tới 4 dependency khác nhau: SwiftGatewayClient, CorrespondentBankService, ExchangeRateService và FeeStrategy. Nếu bạn để mỗi nơi cần gọi SWIFT phải tự new đối tượng và “lắp ráp” dependency, bạn đang tạo ra một mớ hỗn độn khắp codebase.

Giải pháp: Factory Pattern (kết hợp với Registry) tập trung việc tạo object về một mối.

@Component
public class PaymentProcessorFactory {
    private final Map<PaymentMethodType, PaymentProcessor> registry = new HashMap<>();

    // Spring tự động inject tất cả các bean implement PaymentProcessor
    public PaymentProcessorFactory(List<PaymentProcessor> processors) {
        processors.forEach(p -> registry.put(p.getSupportedMethod(), p));
    }

    public PaymentProcessor getProcessor(PaymentMethodType type) {
        PaymentProcessor processor = registry.get(type);
        if (processor == null) {
            throw new UnsupportedOperationException("Chưa hỗ trợ " + type);
        }
        return processor;
    }
}

Tại sao hay?

Testing: Bạn có thể mock PaymentProcessorFactory để trả về processor giả lập, cô lập hoàn toàn tầng Infrastructure.
Mở rộng: Thêm CRYPTO processor? Chỉ cần tạo class mới implement PaymentProcessor, Spring sẽ tự động quét và đưa vào registry.

3. Builder Pattern: Khi Constructor Trở Thành Cơn Ác Mộng

Hãy nhìn vào constructor của một yêu cầu chuyển tiền trong hệ thống ngân hàng thực tế:

// Anti-Pattern: Constructor có quá nhiều tham số, khó đọc và dễ sai vị trí
TransferRequest req = new TransferRequest(
    "ACC001", "ACC002", Money.of(1_000_000), "VietQR",
    null, true, false, null, "HIGH", LocalDateTime.now(), 
    Money.of(50_000), null, true
);

Bạn có chắc mình nhớ null thứ 4 là tham số gì không? (Đó là otp hay reference?)

Giải pháp: Builder Pattern với Fluent API.

TransferRequest req = TransferRequest.builder()
    .fromAccountId("ACC001")
    .toAccountId("ACC002")
    .amount(Money.of(1_000_000))
    .paymentMethod(PaymentMethodType.VIETQR)
    .sendSMS(true)
    .maxFeeLimit(Money.of(50_000))
    .build(); // Validation happens HERE

Bí mật nằm ở build(): Đây là nơi chúng ta áp dụng nguyên tắc Fail-Fast.

public TransferRequest build() {
    if (amount == null || amount.isNegative()) {
        throw new IllegalArgumentException("Số tiền không hợp lệ");
    }
    if (maxFeeLimit != null && estimatedFee.isGreaterThan(maxFeeLimit)) {
        throw new BusinessException("Phí vượt quá giới hạn cho phép");
    }
    return new TransferRequest(this);
}

Điều này đảm bảo rằng một object TransferRequest tồn tại trong hệ thống LUÔN LUÔN hợp lệ. Không còn cảnh “lỗi null amount” bùng nổ ở tầng sâu bên trong PaymentService nữa.

4. Observer Pattern: Giải Phóng Sự Ràng Buộc Của Notifications

Kịch bản quen thuộc: Khi chuyển tiền thành công, bạn cần:

Ghi log kiểm toán (Audit).
Gửi SMS thông báo.
Cập nhật bảng cân đối kế toán.
Kiểm tra gian lận (Fraud Detection).
Gửi Push Notification (yêu cầu mới).

Code “truyền thống” sẽ là một mớ hỗn độn trong method transfer():

transfer.execute();
auditService.log(transfer);   // Blocking call
smsService.send(transfer);    // Blocking call
fraudService.check(transfer); // Cực kỳ chậm (5s)

Nếu fraudService timeout 5 giây, khách hàng sẽ thấy màn hình “Đang xử lý…” quay vòng vòng rồi báo lỗi, mặc dù tiền đã được chuyển đi rồi.

Giải pháp: Observer Pattern với Domain Events.

Thay vì gọi trực tiếp các service khác, TransferMoneyService chỉ cần publish một sự kiện TransferCompletedEvent.

// Service chỉ tập trung vào nghiệp vụ chính
public void transfer(TransferRequest request) {
    // 1. Thực thi chuyển tiền
    processor.execute(request);
    
    // 2. Bắn sự kiện (Fire-and-Forget)
    eventPublisher.publishEvent(new TransferCompletedEvent(...));
}

Các Listener hoàn toàn độc lập:

@Component
public class FraudDetectionListener {
    @EventListener
    @Async // Quan trọng: Xử lý bất đồng bộ
    public void onTransferCompleted(TransferCompletedEvent event) {
        // Dù việc này mất 5 giây cũng không ảnh hưởng tới phản hồi API cho khách hàng
        fraudService.analyze(event);
    }
}

Trade-off: Sử dụng @Async đồng nghĩa với việc chấp nhận Eventual Consistency (tính nhất quán cuối cùng). Có thể SMS đến chậm hơn 2 giây so với lúc tiền vào tài khoản. Nhưng trong hầu hết trường hợp, điều này còn hơn là làm khách hàng tưởng giao dịch lỗi và… chuyển tiền lần nữa (dẫn đến trùng lặp).

5. Decorator Pattern: Thêm Siêu Năng Lực Không Cần Đụng Code Cũ

Bài toán: Manager muốn đo lường Performance Metrics cho từng loại giao dịch (SWIFT chậm hơn VietQR bao nhiêu ms?). Đồng thời muốn tự động Retry khi gọi API NAPAS bị lỗi mạng.

Bạn có định sửa từng class VietQRPaymentProcessor, SWIFTPaymentProcessor để thêm try-catch và timer.record() không? Rõ ràng là không.

Giải pháp: Decorator Pattern.

// Decorator ghi Log
public class LoggingPaymentProcessorDecorator implements PaymentProcessor {
    private final PaymentProcessor delegate;
    
    @Override
    public Money execute(TransferRequest request) {
        log.info("Bắt đầu xử lý {} cho tài khoản {}", 
                 request.getPaymentMethod(), request.getFromAccountId());
        try {
            Money result = delegate.execute(request);
            log.info("Xử lý thành công. Phí: {}", result);
            return result;
        } catch (Exception e) {
            log.error("Xử lý thất bại", e);
            throw e;
        }
    }
}

Lắp ráp các Decorator (Stacking):

PaymentProcessor rawProcessor = factory.getProcessor(PaymentMethodType.VIETQR);
PaymentProcessor withRetry = new RetryPaymentProcessorDecorator(rawProcessor, 3);
PaymentProcessor withMetrics = new MetricsPaymentProcessorDecorator(withRetry, meterRegistry);
PaymentProcessor finalProcessor = new LoggingPaymentProcessorDecorator(withMetrics);

// Bây giờ processor đã có Retry -> Metrics -> Logging mà code gốc không hề hay biết

Đây chính là nguyên lý Open/Closed Principle trong SOLID: Mở cho việc mở rộng, đóng cho việc chỉnh sửa.

6. Chain of Responsibility: Đường Ống Xác Thực Nhiều Tầng

Trong ngân hàng, việc xác thực một giao dịch chuyển tiền không chỉ đơn giản là kiểm tra số dư. Nó là một quy trình gồm nhiều bước:

Tài khoản có tồn tại và không bị khóa?
Số dư có đủ + hạn mức thấu chi?
Có vượt quá hạn mức giao dịch trong ngày?
Có nằm trong danh sách cảnh báo gian lận (Fraud)?
Có nằm trong danh sách cấm vận (AML/Sanctions)?

Nếu viết một method validate() dài 300 dòng cho tất cả việc này, bạn sẽ gặp khó khăn khi muốn thay đổi thứ tự kiểm tra hoặc chèn thêm một bước kiểm tra mới (ví dụ: kiểm tra thiết bị lạ).

Giải pháp: Chain of Responsibility.

Mỗi bước kiểm tra là một Handler riêng biệt.

public abstract class ValidationHandler {
    protected ValidationHandler next;
    
    public void setNext(ValidationHandler next) {
        this.next = next;
    }
    
    public abstract void handle(TransferRequest request);
}

// Sử dụng
ValidationHandler chain = new BalanceHandler(accountRepo);
chain.setNext(new LimitHandler(historyService));
chain.getNext().setNext(new FraudHandler(fraudService));

chain.handle(request); // Thực thi tuần tự cho đến khi gặp lỗi hoặc hết chuỗi

Khi có yêu cầu mới “Kiểm tra thiết bị đăng nhập”, bạn chỉ cần tạo DeviceFingerprintHandler và chèn vào chuỗi mà không cần sửa các Handler còn lại.

7. Những Cái Bẫy Chết Người (Trade-Offs & Anti-Patterns)

Sau nhiều năm “chiến đấu” với các pattern này, tôi đã rút ra vài bài học máu xương mà bạn nên nằm lòng:

❌ 1. Pattern Fever (Hội Chứng Lạm Dụng Pattern)

Đừng dùng Factory nếu chỉ có 2 loại object và logic khởi tạo chỉ là new A() hoặc new B().

Hậu quả: Code trở nên khó đọc hơn do có thêm một tầng gián tiếp không cần thiết.
Khắc phục: Dùng if-else hoặc toán tử 3 ngôi ? :. Đơn giản là vua.

❌ 2. Observer Đồng Bộ (The Silent Performance Killer)

Mặc định, @EventListener trong Spring chạy đồng bộ (cùng thread với Publisher). Nếu bạn có 1 listener gọi SMS gateway mất 3 giây, API của bạn sẽ chậm 3 giây.

Khắc phục: Luôn cân nhắc đánh dấu @Async cho các tác vụ không ảnh hưởng đến kết quả trả về tức thì.

❌ 3. Builder Không Validation

Xây nhà mà không có móng. Nếu build() không kiểm tra tính hợp lệ, bạn chỉ đơn giản là đang dùng một cái Constructor “dài dòng” hơn mà thôi.

Nguyên tắc vàng: Đối tượng khi ra khỏi build() phải hoàn hảo.

❌ 4. Nhầm Lẫn Giữa Decorator và Kế Thừa

Đừng tạo class LoggingVietQRProcessor extends VietQRProcessor. Bạn sẽ phải tạo LoggingSWIFTProcessor, LoggingNAPASProcessor, rồi sau đó là MetricsLoggingVietQRProcessor… Một mớ bòng bong N x M class.

Khắc phục: Dùng Composition (Decorator) . “Gói” đối tượng thay vì “Kế thừa” nó.

Kết Luận: Làm Sao Để Nhớ Hết Chỗ Này?

Design Patterns không phải là cây đũa thần. Chúng là công cụ. Dùng sai công cụ sẽ làm hỏng việc. Hãy tự hỏi bản thân những câu hỏi “Sát Thủ” dưới đây khi code. Nếu bạn trả lời được mà không cần nhìn tài liệu, bạn đã thực sự thông thạo:

Strategy vs If-Else: Hệ thống có 3 loại phí. Khi nào thì if-else là tội ác, khi nào thì Strategy là thừa thãi?
Factory Testing: Làm sao để mock một Factory để test nghiệp vụ mà không cần khởi tạo cả tá dependency thật?
Builder Validation: Nên đặt logic kiểm tra “Số tiền tối đa không vượt quá số dư” ở setter của Builder hay ở build()?
Observer Hell: Nếu SMS Listener bắn @Async nhưng bị lỗi, làm sao để đảm bảo khách hàng VẪN NHẬN ĐƯỢC TIN NHẮN sau khi hệ thống khôi phục?
Chain Order: Thứ tự Handler trong Chain ảnh hưởng đến performance như thế nào? (Gợi ý: Nên kiểm tra số dư trước hay kiểm tra AML trước?).

Hy vọng bài viết này đã mang đến cho bạn một góc nhìn thực tế về cách áp dụng GoF Patterns trong môi trường khắc nghiệt của ngành Ngân hàng. Đừng ngại áp dụng chúng, nhưng hãy luôn nhớ câu thần chú: “Keep It Simple, Stupid!” cho đến khi sự phức tạp thực sự đòi hỏi một giải pháp thanh lịch hơn.

Design Patterns: Khi GoF Cứu Rỗi Một Hệ Thống Thanh Toán