Databases

Prinsip:

1. Flexible to use.
2. Ideal for professional SaaS.
3. Complete and ready.

Multi-tenant indexing, explicit bounded context, external scalar references, immutable transaction snapshots, financial entities terpisah.

Domains

Domain database dibagi menjadi empat services yang terpisah. Setiap client hanya mereferensikan schema database berdasarkan domainnya.

Database Provider

Saat ini semua database menggunakan provider MongoDB.

Object-Relational Mapping

Object-Relational Mapping (ORM) yang digunakan untuk mengelola semua schema database adalah Prisma versi 6.15.0, sebagai jalur MongoDB yang stabil, Prisma 7 banyak yang tidak didukung untuk MongoDB, sementara Prisma 8 memiliki jalur MongoDB baru; detail client/API-nya berbeda. (Prisma)

Baca juga tips.

Referential integrity

Cross-database ID seperti organizationId, productId, dan memberId adalah scalar. Service harus melakukan lookup ke owner database sebelum write dan menolak reference yang tidak valid.

Tidak ada transaksi ACID lintas client. Untuk workflow multi-database, gunakan idempotency key, ordered writes, retry yang aman, dan compensation. Jangan menampilkan generated Prisma client pada client bundle.

Konvensi global

Money: BigInt
 
Quantity: Int + quantityScale
 
Ratio / percentage: Float hanya jika memang sifatnya numerik aproksimatif

Contoh:

1.25 kg
 
quantityScale = 2
quantity = 125

dan bukan:

quantity = 1.25;

Sehingga:

Catalog
    ↓
Commerce
    ↓
Inventory

menggunakan representasi type field yang identik dan tidak ada conversion boundary berbasis IEEE-754 Float pada quantity.

Catatan Prisma/MongoDB

Composite types yang digunakan pada schema memang merupakan fitur MongoDB Prisma dan cocok untuk embedded value objects. (Prisma)

MongoDB Prisma juga mendukung transaction API pada Prisma v6; dokumentasi v6 menyatakan MongoDB menggunakan transaction untuk nested/multi-operation writes dan membutuhkan deployment replica set. (Prisma)

Untuk Inventory, ini bukan sekadar nice-to-have. Operasi seperti:

reserve stock
+ update WarehouseStock
+ update LotBalance

dan:

transfer
+ source movement
+ destination movement
+ lot balances

harus diperlakukan sebagai atomic business operation.

Jadi environment production harus menggunakan MongoDB replica set/Atlas.

Verdict

Dengan desain ini saya menilai Inventory sudah berada pada level yang jauh lebih dekat ke:

Flexible → bisa menangani retail, warehouse, workshop/service, spare part, serialized equipment, batch goods, multi-warehouse, lot expiry, transfer, reservation, stock opname.

Professional SaaS → multi-tenant, immutable ledger, idempotency, concurrency control, reservation, historical traceability, cost layer, archive semantics, cross-domain isolation.

Complete → warehouse → bin → item → stock → lot → serial → reservation → operation → movement → transfer → stocktake seluruhnya memiliki boundary yang jelas.

Yang paling penting, schema ini tidak lagi sekadar menyimpan "quantity", tetapi sudah membentuk inventory engine: current state, physical state, reservation state, historical ledger, cost layer, dan operational workflows dipisahkan dengan benar.

Ada satu hal yang saya anggap wajib sebelum Catalog + Commerce + Inventory benar-benar saya sebut satu ekosistem schema final: menyelaraskan seluruh Float quantity pada Catalog dan Commerce menjadi fixed-point quantity yang sama dengan Inventory. Ini akan menghilangkan satu-satunya boundary numerik yang masih berpotensi merusak ketelitian stock movement di ketiga domain.

Migration

Sebelum menerapkan perubahan schema model ke database production, perubahan tersebut sebaiknya dimigrasikan dalam beberapa tahap agar historical data tidak hilang.