Middleware: Menjaga Sistem Operasional Tidak Terikat pada Satu Accounting Platform

Ketika sistem operasional terhubung ke accounting platform, solusi paling cepat sering terlihat sederhana: panggil API provider langsung dari aplikasi utama.

Untuk kebutuhan kecil, itu mungkin cukup.

Tetapi ketika transaksi, mapping, retry, reconciliation, dan kemungkinan mengganti provider mulai bertambah, coupling tersebut menjadi mahal.

Sistem operasional dan accounting punya bahasa berbeda

Sistem operasional berpikir tentang customer, order, keberangkatan, pembayaran, perlengkapan, atau aktivitas bisnis.

Accounting berpikir tentang invoice, account, journal, receivable, payable, recognition, dan reconciliation.

Keduanya berhubungan, tetapi tidak identik.

Integration layer memberi tempat untuk menerjemahkan bahasa tersebut tanpa membuat domain operasional dipenuhi ID dan struktur provider.

Mapping harus punya ownership

Identifier internal sebaiknya tidak bergantung langsung pada identifier accounting provider. Middleware bisa menyimpan mapping, canonical model, idempotency key, sync status, dan audit trail.

Dengan begitu aplikasi utama tetap memahami konsep bisnisnya sendiri.

Failure adalah bagian dari desain

API bisa timeout. Data bisa ditolak karena validation. Provider bisa unavailable. Payment yang sama tidak boleh terkirim dua kali.

Karena itu integrasi bukan hanya persoalan membuat request HTTP berhasil.

Kita perlu menentukan retry strategy, business error, reconciliation, manual review, dan visibility ketika sinkronisasi gagal.

Integration layer juga memberi opsi masa depan

Saya tidak suka membuat architecture berdasarkan asumsi bahwa provider yang dipakai hari ini pasti dipakai selamanya.

Abstraction tidak perlu berlebihan. Tetapi boundary yang sehat memberi perusahaan ruang untuk berubah tanpa membongkar seluruh sistem operasional.

Bagi saya, middleware bukan sekadar “API di tengah”.

Ia adalah tempat untuk menjaga kontrak antara dua dunia yang punya tanggung jawab berbeda.