Arsitektur Aori

Aori adalah business operating system SaaS multi-tenant. Sistem ini membedakan identity global, tenant Organization, akses Member, employment Employee, dan ruang kerja Workspace. Pemisahan tersebut mencegah aplikasi memperlakukan semua User sebagai owner organisasi atau semua Member sebagai Employee.

Bentuk monorepo

apps/app/container adalah host micro-frontend untuk aplikasi utama. Ia menangani shell, session-aware access gate, route, serta integrasi API yang aman.
apps/app/* adalah consumer UI. Kontrak antarmicro-frontend berada di @contracts/*; package reusable lintas repository berada di @repo/* dalam packages/*.
apps/api adalah boundary server untuk autentikasi, validasi manual, authorization, tenant scope, rate limit, dan orkestrasi domain. Browser tidak pernah membaca Prisma atau database secara langsung.
apps/docs menerbitkan dokumen engineering dan blueprint yang digunakan contributor.

Owner data dan lima database

Database	Owner dan tanggung jawab	Tidak boleh menjadi owner
Runner	identity, session, Organization, Member, RBAC, Team, Workspace, Collaboration, HR	product, order, atau stock
Billing	plan, Subscription, Entitlement, usage, tagihan Aori kepada tenant	permission actor atau Commerce invoice
Catalog	product/service, PriceList, Price, promotion	stock maupun order
Commerce	customer, cart, order, customer invoice, payment, shipment	Billing invoice atau authority actor
Inventory	warehouse, reservation, stock, immutable movement	harga browser atau ownership product

organizationId pada database lain merupakan scalar tenant key, bukan Prisma foreign key lintas database. Tidak ada join, transaction, relation, atau cascade lintas lima database. Reference lintas domain menggunakan ID dan snapshot minimal yang tervalidasi.

Alur request dan mutasi

User agent
  -> Container / aplikasi consumer
  -> authenticated API proxy
  -> request context, origin/CORS/CSRF dan rate-limit boundary
  -> router parameter/query/body validation
  -> session actor + tenant scope + permission check
  -> domain service dan database owner
  -> projection HTTP aman / invalidation UI

Untuk capability berbayar, domain menjalankan dua pemeriksaan berbeda: entitlement tenant menentukan apakah fitur atau quota tersedia, sedangkan permission menentukan apakah actor boleh melakukan aksi. Salah satu tidak menggantikan yang lain.

Mutasi lintas domain tidak dilakukan dengan join atau transaction lintas database. Domain owner menyimpan perubahan lokal dan outbox idempoten dalam transaksi yang sama; publisher dan inbox consumer kemudian membangun projection atau menjalankan kompensasi. BigInt money selalu merupakan minor unit dan diserialisasi sebagai string pada HTTP.

Boundary kerja sama dan operasi

Organization adalah tenant root dan pemilik sah Workspace. Workspace selalu dimiliki satu Organization; participant eksternal tetap Member pada Organization asal dan hanya mendapat scope terbatas melalui Collaboration aktif. Team adalah kelompok internal stabil, Project adalah deliverable, sedangkan Collaboration menyimpan party, scope, approval, dokumen, dan landasan legal untuk bekerja bersama.

Archive bukan delete: riwayat audit, payroll, harga, transaksi, atau dokumen yang telah terbentuk tidak boleh hilang dari aksi operasional biasa. Purge hanya dapat terjadi melalui retention policy, legal-hold check, pemberitahuan, export window, dan audit.

Cara memakai dokumen ini

Halaman ini adalah orientasi tingkat tinggi, bukan spesifikasi operasional lengkap. Untuk detail lengkap mengenai vocabulary, ownership, lifecycle, distributed consistency, dan boundary implementasi, kunjungi Blueprint Overview. Untuk urutan kerja aktual kunjungi Execution Roadmap, dan untuk pengujian invariant melalui peristiwa bisnis kunjungi Business Study.