Stored procedures và workflow trực quan: logic nên đặt ở đâu?

Quyết định này thực sự nghĩa là gì

Business logic là tập hợp các quy tắc quyết định những gì được phép, điều gì xảy ra tiếp theo, và hệ thống nên làm gì khi người thật thao tác. Đó không phải là dữ liệu mà là hành vi: ai có thể làm gì, trong điều kiện nào, và với các tác động phụ như thế nào.

Vậy cuộc tranh luận giữa stored procedures và visual workflows thực ra là về nơi những quy tắc này nên sống để chúng dễ thay đổi, khó phá vỡ và rõ ràng với những người chịu trách nhiệm quy trình.

Hầu hết các đội cuối cùng có ba “nhà” có thể đặt logic:

• Trong database (stored procedures, triggers, constraints): quy tắc chạy gần dữ liệu. Điều này có thể nhanh và nhất quán, nhưng khó cho người không chuyên về database để thay đổi.
• Trong visual workflows (trình kéo-thả, trình xây dựng quy trình): quy tắc được biểu đạt dưới dạng các bước và quyết định. Thường dễ đọc, dễ review và điều chỉnh khi quy trình thay đổi.
• Trong custom code (services, apps, script): quy tắc viết bằng ngôn ngữ lập trình. Điều này cho độ linh hoạt tối đa, nhưng thay đổi thường cần kỷ luật kỹ thuật hơn và kiểm thử.

Lựa chọn ảnh hưởng đến tốc độ làm việc hàng ngày và bảo trì lâu dài. Đặt logic sai chỗ và bạn sẽ có giao hàng chậm (mỗi thay đổi cần người duy nhất biết database), nhiều lỗi hơn (quy tắc bị nhân bản ở nhiều nơi), và debug đau đầu (không ai biết tại sao một bản ghi bị từ chối).

Hầu hết hệ thống chứa nhiều loại business logic. Ví dụ phổ biến gồm xác thực (trường bắt buộc, phạm vi cho phép), phê duyệt, định giá và chiết khấu, thông báo, và quy tắc truy cập.

Cách thực tế để nghĩ về nó: database giỏi bảo vệ tính toàn vẹn dữ liệu, visual workflows giỏi diễn đạt quy trình kinh doanh, và custom code phù hợp khi quy tắc quá độc đáo hoặc phức tạp để mô hình hoá rõ ràng. Các nền tảng như AppMaster nằm ở giữa: bạn có thể mô hình dữ liệu rồi triển khai quy trình bằng logic trực quan dễ đọc mà không phân tán quy tắc khắp các ứng dụng.

Tiêu chí: bạn đang tối ưu cho điều gì

Đây không chỉ là câu hỏi sở thích. Là về việc bạn cố gắng bảo vệ điều gì: dữ liệu, người thay đổi hệ thống, và tốc độ thay đổi.

Các kết quả quan trọng

Xác định kết quả hàng đầu cho dự án. Hầu hết đội cân bằng giữa những mục này:

• Đúng đắn (Correctness): quy tắc phải chạy giống nhau mọi lần, ngay cả dưới tải lớn.
• Rõ ràng (Clarity): người mới nên hiểu được điều gì xảy ra mà không phải suy đoán.
• Tốc độ (Speed): logic phải chạy nhanh và gần dữ liệu khi cần.
• Khả năng kiểm toán (Auditability): bạn cần chứng minh ai thay đổi gì, và khi nào nó chạy.
• Tần suất thay đổi (Change rate): yêu cầu có thể thay đổi hàng tuần, không phải hàng năm.

Hiếm khi bạn tối đa hoá cả năm. Đẩy logic sát database có thể cải thiện correctness và speed, nhưng giảm clarity cho người không quen SQL.

Ai sẽ thay đổi logic (và tần suất)

Thành thật về người sở hữu thay đổi hàng ngày. Một quy tắc mà ops cần điều chỉnh hàng tuần không nên yêu cầu DBA deploy một stored procedure. Đồng thời, quy tắc ảnh hưởng đến tiền bạc thì không nên chỉnh sửa mà không có review.

Suy nghĩ theo ma sát thay đổi. Nếu yêu cầu thay đổi thường, bạn cần nơi cập nhật an toàn, dễ thấy và nhanh để deploy. Công cụ visual workflow (ví dụ Business Process Editor của AppMaster) phù hợp khi chủ doanh nghiệp và kỹ sư cần cộng tác về logic mà không sửa code thấp.

Một cách nhanh để thử tính sở hữu:

• Ai bị gọi khi hỏng lúc 2 giờ sáng?
• Cần bao nhanh để patch một quy tắc?
• Thay đổi có cần phê duyệt hoặc lưu giấy tờ không?
• Có nhiều ứng dụng phụ thuộc vào cùng một quy tắc không?
• Logic chủ yếu là định hình dữ liệu hay quyết định kinh doanh?

Ghi nhận các ràng buộc sớm. Một số ngành yêu cầu kiểm soát truy cập nghiêm ngặt, tách nhiệm vụ, hoặc log chi tiết. Cân nhắc giới hạn truy cập dữ liệu: nếu chỉ một vài service nên thấy một số trường nhất định, điều đó ảnh hưởng nơi logic có thể chạy an toàn.

Khi logic thuộc về stored procedures

Stored procedures là các đoạn logic chạy trong database. Trong PostgreSQL, chúng viết bằng SQL (và đôi khi ngôn ngữ cơ sở dữ liệu như PL/pgSQL). Thay vì app kéo bản ghi ra, lặp và đẩy thay đổi về, database làm việc ngay nơi dữ liệu nằm.

Một quy tắc đơn giản: đặt logic vào database khi nhiệm vụ chính là bảo vệ dữ liệu và xử lý khối lượng lớn dữ liệu, không phải điều phối con người hoặc hệ thống.

Nơi stored procedures tỏa sáng

Stored procedures phù hợp với các quy tắc phải luôn đúng, bất kể app hay tích hợp nào chạm vào database. Nghĩ về các hàng rào bảo vệ để chặn dữ liệu xấu.

Chúng cũng xuất sắc cho cập nhật theo tập, nơi một câu lệnh có thể cập nhật hàng nghìn hàng một cách an toàn và nhanh. Các phép tính đơn giản thuần về dữ liệu, như tính tổng hoặc áp dụng công thức chiết khấu cố định, cũng có thể đặt ở đây khi giảm vòng đi vòng lại và giữ kết quả nhất quán.

Ví dụ: khi một đơn hàng được đánh dấu paid, một procedure có thể cập nhật trạng thái đơn hàng, giảm tồn kho và ghi một dòng audit trong một thao tác nguyên tử. Nếu bước nào thất bại, toàn bộ thay đổi rollback.

Khi stored procedures trở nên rủi ro

Stored procedures có thể khó test và version hơn code ứng dụng, đặc biệt nếu đội không đối xử thay đổi cơ sở dữ liệu như các release thực thụ. Logic cũng có thể bị “ẩn” khỏi app, tạo coupling bạn chỉ phát hiện sau này.

Debug cũng khó hơn. Lỗi có thể xuất hiện dưới dạng thông điệp database với ít ngữ cảnh về hành động người dùng. Người mới có thể gặp khó vì quy tắc tách rời giữa app và database, và logic trong DB dễ bị bỏ sót khi onboarding.

Nếu bạn dùng tool trực quan cho hầu hết logic, hãy dành stored procedures cho phần lõi nhỏ, ổn định cần chạy gần dữ liệu. Giữ mọi thứ khác ở nơi dễ đọc, dễ theo dõi và dễ thay đổi.

Khi logic phù hợp với visual workflows

Visual workflows là logic theo bước mà bạn có thể đọc như checklist: khi có sự kiện, chạy những hành động này theo thứ tự, với các điểm quyết định rõ ràng. Chúng ít dùng cho tính toán nặng mà nhiều hơn cho cách công việc di chuyển qua con người, hệ thống và thời gian.

Chúng tỏa sáng khi bạn quan tâm tới sự hiểu chung. Nếu product, ops, support và engineering đều cần đồng ý cách một quy trình vận hành, workflow trực quan làm cho quy tắc hiển thị. Sự minh bạch này thường là khác biệt giữa “hệ thống hỏng” và “quy trình đã thay đổi tuần trước.”

Workflow phù hợp cho phê duyệt và review, định tuyến, thông báo và nhắc nhở, bước theo thời gian (chờ 2 ngày rồi eskalate), và tích hợp (gọi Stripe, gửi tin, cập nhật CRM).

Ví dụ: khách hàng yêu cầu hoàn tiền. Workflow kiểm tra tuổi đơn hàng, điều hướng đến quản lý nếu vượt ngưỡng, thông báo cho finance khi được chấp thuận và gửi cập nhật cho khách. Mỗi bước dễ chỉ và thảo luận bằng ngôn ngữ đơn giản, giúp các bên liên quan đồng ý và giúp người mới hiểu “tại sao”.

Công cụ như Business Process Editor của AppMaster được thiết kế cho loại logic này: bạn có thể thấy luồng, điều kiện và tác động phụ (tin nhắn, API call, thay đổi trạng thái) mà không phải mò qua script database.

Để tránh workflows thành spaghetti, giữ chúng nhỏ và dễ đọc. Cho mỗi workflow một kết quả, đặt tên bước và nhánh rõ ràng, hạn chế lồng sâu và ghi log các lựa chọn chính để sau này trả lời được “tại sao điều này xảy ra?”.

Khi một workflow bắt đầu thực hiện xử lý dữ liệu phức tạp hoặc chạm nhiều bảng, đó thường là dấu hiệu nên dời một phần logic ra chỗ khác. Workflow trực quan làm tốt vai “nhạc trưởng”, không phải toàn bộ dàn nhạc.

Khi custom code là công cụ phù hợp

Custom code là logic bạn viết và bảo trì như phần mềm: hàm, service, hoặc thư viện nhỏ chạy trong app. Đây là lựa chọn linh hoạt nhất, và vì vậy nên dùng có chủ đích, không mặc định.

Code có chỗ đứng khi logic khó biểu đạt an toàn trong stored procedure hoặc workflow kéo-thả. Nếu bạn thấy đang uốn công cụ để phù hợp với vấn đề, code thường rõ ràng hơn và dễ giữ đúng.

Dấu hiệu mạnh nên dùng code:

• Vấn đề mang tính thuật toán (quy tắc định giá, lập tuyến, scoring, ghép) và có nhiều edge case.
• Cần tích hợp bất thường (API đối tác với auth lạ, retry phức tạp, yêu cầu idempotency chặt).
• Nhạy cảm hiệu năng (xử lý khối lượng lớn, tính toán nặng, caching) và bạn cần kiểm soát chặt.
• Phải chia sẻ cùng logic ở nhiều nơi (web, mobile, batch) mà không copy.
• Cần test tự động mạnh xung quanh logic vì lỗi rất đắt.

Code cũng làm rõ hơn về sở hữu. Một đội có thể chịu trách nhiệm review thay đổi, giữ test xanh, và ghi chép hành vi. Điều đó tốt hơn việc “nó sống trong ba workflow và không ai chắc cái nào chạy trước”.

Ví dụ: engine quyết định hoàn tiền xét lịch sử đơn hàng, tín hiệu gian lận, trạng thái vận chuyển, và khung thời gian. Bạn vẫn có thể giữ các bước phê duyệt trong workflow trực quan, nhưng quyết định thường tốt hơn khi là code có unit test và version control.

Chi phí là có thực. Custom code cần thời gian engineering, review và bảo trì. Thay đổi có thể lâu hơn so với chỉnh workflow và cần quy trình release. AppMaster có thể giảm lượng code cần viết bằng cách che phủ các phần phổ biến bằng logic trực quan và module, trong khi vẫn cho phép export source khi cần mở rộng thực sự.

Khung làm việc theo bước bạn có thể dùng lại

Các đội thường bỏ qua phần hữu ích nhất: viết rõ quy tắc, rồi chọn chỗ phù hợp dựa trên cách quy tắc hoạt động.

Dùng khung này khi xuất hiện logic mới:

• Viết quy tắc thành một câu, rồi gắn nhãn. Nếu nó về dữ liệu hợp lệ (ràng buộc, duy nhất, tổng phải khớp), đó là data rule. Nếu về bước và bàn giao (phê duyệt, chờ, thông báo), là process rule. Nếu là toán học nặng hoặc biến đổi phức tạp, là computation rule.
• Hỏi ai chỉnh và tần suất. Nếu người không chuyên cần thay đổi hàng tuần, đừng chôn vào SQL hoặc release code. Nếu hiếm khi thay đổi và cần thi hành mọi lúc, database là ứng viên mạnh.
• Kiểm tra tác động khi lỗi và audit cần gì. Nếu sai sót gây mất tiền, vấn đề tuân thủ, hoặc dữ liệu khó sửa, ưu tiên nơi có log rõ ràng và kiểm soát chặt.
• Chọn vị trí và xác định ranh giới. Rõ ràng về inputs, outputs và lỗi. Ví dụ: “Given an order_id, return allowed_refund_amount or a clear reason code.” Ranh giới đó giữ logic khỏi bị lan tràn.
• Chọn một lớp giữ mỏng. Quyết định phần nào nên “ngu” để không nhân bản quy tắc. Lựa chọn thông thường: giữ database mỏng (chỉ tính toàn vẹn dữ liệu), giữ workflows mỏng (chỉ điều phối), hoặc giữ code mỏng (chỉ glue).

Quy tắc thông thường: đặt quy tắc dữ liệu gần dữ liệu nhất, đặt quy tắc quy trình trong công cụ workflow, và đặt quy tắc tính toán nơi dễ test và version nhất.

Nếu dùng nền tảng như AppMaster, bạn có thể coi database như hàng rào bảo vệ (bảng, quan hệ, ràng buộc cơ bản) và dùng Business Process Editor trực quan cho phần “ai làm gì tiếp theo”, trong khi để custom code cho vài trường hợp cần thiết.

Sai lầm phổ biến khiến hệ thống lộn xộn

Hệ thống lộn xộn hiếm khi xảy ra vì một lựa chọn sai. Thường là khi logic bị phân tán, ẩn, hoặc sao chép tới mức không ai biết hệ thống thực sự làm gì.

Nhân bản là vấn đề kinh điển: cùng một quy tắc tồn tại ở hai nơi nhưng sai lệch theo thời gian. Ví dụ: database từ chối hoàn tiền trên $500 nếu không có record phê duyệt, nhưng workflow vẫn gửi yêu cầu thanh toán vì nó kiểm tra ngưỡng khác. Cả hai “hoạt động” cho tới khi gặp edge case thật, rồi support nhận được bug bí ẩn.

Quy tắc ẩn là tiếp theo. Triggers, stored procedures, và sửa nhanh trong database có thể vô hình với người xây UI hoặc workflow. Nếu quy tắc không được document gần workflow hoặc API phụ thuộc vào nó, thay đổi thành suy đoán và test thành thử nghiệm thử-and-error.

Workflow quá tải tạo loại rắc rối khác. Một chuỗi kéo-thả dài với hàng chục nhánh trở thành mảnh dễ vỡ mà không ai muốn đụng tới. Trong công cụ như AppMaster, rất dễ thêm khối vì nhanh, nhưng tốc độ hôm nay có thể biến thành bối rối sau này nếu workflow không có ranh giới rõ ràng.

Hai sai lầm “quá nhiều” đối nghịch gây đau lâu dài:

• Quá nhiều ở database: mỗi thay đổi chính sách thành dự án migration, và các tinh chỉnh nhỏ phải chờ release database.
• Quá nhiều trong app code: các quy tắc dữ liệu cơ bản (trường bắt buộc, trạng thái cho phép, ràng buộc duy nhất) bị quên, và dữ liệu xấu lọt qua import, công cụ admin hoặc tích hợp sau này.

Một thói quen đơn giản ngăn hầu hết: giữ mỗi quy tắc ở một nơi chính, và ghi rõ nơi nó sống và lý do. Nếu bạn không trả lời được “nơi này được thi hành ở đâu?” trong 10 giây, bạn đang trả tiền cho sự lộn xộn.

Kiểm tra nhanh: quyết định trong 2 phút

Bạn đang chọn nơi một quy tắc dễ giữ đúng, hiển thị và thay đổi.

Bắt đầu với một câu hỏi: quy tắc này về tính đúng dữ liệu không, tức là không được bỏ qua? Nếu có, đẩy nó sát database. Nếu là về bước, phê duyệt hoặc thông báo, giữ nó gần lớp workflow.

Checklist nhanh:

• Nó thực thi tính đúng dữ liệu (ngăn tồn kho âm, chặn bản ghi “active” trùng)? Hướng tới database.
• Nó chạm nhiều bảng và cần cập nhật theo tập? Hướng tới database.
• Cần audit rõ ràng ai phê duyệt gì và khi nào? Hướng workflow.
• Người không phải kỹ sư cần thay đổi hàng tuần hoặc hàng tháng? Hướng workflow.
• Gọi dịch vụ ngoài (payments, messaging, AI)? Hướng ứng dụng hoặc workflow, không phải database.

Bây giờ nghĩ về thất bại. Một quy tắc có thể lỗi nên lỗi theo cách con người có thể khôi phục. Nếu cần retry an toàn và thông báo lỗi rõ ràng, ưu tiên orchestration layer nơi bạn có thể theo dõi trạng thái và xử lý ngoại lệ từng bước. Các công cụ workflow trực quan thường làm điều này dễ hơn vì mỗi bước rõ ràng và có thể log.

Một tie-breaker thực tế:

• Nếu hệ thống phải đúng ngay cả khi ai đó viết app mới sau này, enforce ở database.
• Nếu quy trình cần đọc và review bởi đội ops, giữ ở workflow trực quan.
• Nếu liên quan tích hợp phức tạp, tính toán nặng, hoặc thư viện đặc thù, dùng custom code.

Ví dụ: “Refund amount cannot exceed original payment” là tính đúng, nên enforce gần dữ liệu. “Refunds over $500 require manager approval and then send a Telegram message” là workflow. Trong AppMaster, chuỗi phê duyệt đó phù hợp trong Business Process Editor, còn ràng buộc nghiêm ngặt ở mô hình dữ liệu.

Kịch bản ví dụ: hoàn tiền có phê duyệt

Một trường hợp phổ biến là hoàn tiền cần phê duyệt quản lý trên mức nhất định, kèm thông báo và audit rõ ràng.

Bắt đầu bằng việc định nghĩa một nguồn chân lý duy nhất: một bản ghi Refund với số tiền và trường trạng thái rõ ràng (ví dụ: requested, needs_approval, approved, rejected, processing, paid, failed). Mọi phần trong hệ thống nên đọc và ghi cùng các trường này, thay vì giữ trạng thái song song ở nơi khác.

Điều gì nên ở trong database

Đặt các quy tắc bảo vệ tiền và tính nhất quán dữ liệu gần dữ liệu nhất.

Dùng constraints (và đôi khi stored procedure) để đảm bảo bạn không hoàn nhiều hơn số tiền đã thu, không hoàn đơn đã hoàn hết, không tạo hai yêu cầu refund active cho cùng một order, hoặc thay đổi các số tiền chính sau khi refund đã được phê duyệt.

Cũng giữ cập nhật nguyên tử ở đây: khi tạo yêu cầu refund, ghi bản ghi Refund và cập nhật tổng Order trong cùng một transaction. Nếu một write thất bại, không có gì cập nhật một phần.

Điều gì phù hợp trong visual workflow

Các bước phê duyệt là quy trình, không phải bảo vệ dữ liệu. Workflow trực quan là nơi tốt cho việc điều hướng yêu cầu tới đúng quản lý, chờ quyết định, cập nhật trạng thái, gửi nhắc nhở và thông báo cho người yêu cầu.

Một luồng đơn giản có thể là: tạo yêu cầu -> nếu số tiền vượt giới hạn, đặt trạng thái needs_approval -> thông báo quản lý -> nếu chấp thuận, đặt approved -> thông báo cho người yêu cầu -> nếu không phản hồi trong 24 giờ, gửi nhắc.

Trong công cụ như AppMaster, điều này map tự nhiên thành một Business Process phản ứng theo thay đổi trạng thái và kích hoạt email, SMS hoặc Telegram.

Điều gì nên là custom code

Các nhà cung cấp thanh toán có edge case không luôn gói gọn vào quy tắc hay khối kéo-thả. Giữ logic đặc thù provider trong custom code, ví dụ partial refunds có phí hoặc multi-capture payments, reconciliation webhook (provider nói “paid” nhưng app bạn ghi “processing”), và xử lý idempotency cùng retry khi provider timeout.

Chìa khoá là custom code không nên phát minh trạng thái riêng. Nó đọc bản ghi Refund, thực hiện hành động với provider, rồi ghi lại trạng thái tiếp theo và số tiền xác nhận để database vẫn là sổ cái mọi người tin tưởng.

Bước tiếp theo: làm cho quyết định tồn tại lâu dài

Quyết định tốt chỉ hữu ích nếu nó còn đúng sau sáu tháng. Mục tiêu là làm cho lựa chọn “logic nên sống ở đâu?” dễ thấy, dễ test và khó bỏ qua vô tình.

Tạo một logic map đơn giản: danh sách ngắn các quy tắc quan trọng và nơi bạn đặt mỗi quy tắc. Giữ ngắn và cập nhật khi quy tắc thay đổi. Bao gồm tên quy tắc, nơi nó sống (database, workflow, custom code), lý do (một câu), nó đọc và ghi gì, và ai phê duyệt thay đổi.

Ghi ranh giới như các nguyên tắc bất khả xâm phạm để bảo vệ hệ thống khi người ta thêm tính năng. Một định dạng hữu ích: “The database guarantees X” và “Workflows enforce Y.” Ví dụ, database đảm bảo một refund không tồn tại nếu không có order, còn workflow đảm bảo refund trên $500 cần phê duyệt quản lý.

Lên kế hoạch kiểm thử trước khi thay đổi. Bạn không cần kế hoạch to, chỉ vài trường hợp sẽ chạy lại mỗi khi quy tắc thay đổi:

• Happy path (đầu vào mong đợi, kết quả mong đợi)
• Failure path (thiếu dữ liệu, trạng thái không hợp lệ, yêu cầu trùng lặp)
• Concurrency (hai người kích hoạt cùng hành động cùng lúc)
• Security (người dùng cố né bước hoặc gọi endpoint trực tiếp)

Đặt sở hữu và quy tắc review nữa. Quyết định ai được quyền chỉnh stored procedures, ai chỉnh workflows, và gì cần peer review. Đó là nơi nhiều hệ thống hoặc khỏe mạnh hoặc trôi vào “không ai biết tại sao nó hoạt động”.

Nếu bạn muốn workflow kéo-thả mà không mất cấu trúc backend thực sự, nền tảng như AppMaster (appmaster.io) có thể là lựa chọn trung gian thực dụng: mô hình dữ liệu, diễn đạt quy trình trong Business Process Editor, rồi generate và deploy khi yêu cầu thay đổi.

Chọn một quy tắc có ảnh hưởng lớn, map nó, thêm ranh giới, và viết ba test case. Thói quen đơn này ngăn hầu hết sự lan tỏa logic.