System Architecture

ثلاث قنوات، Commerce Core واحد.

App وWeb وAdmin تختلف في التجربة، لكنها لا تملك قواعد تجارة منفصلة. السعر، المخزون، التوصيل، السعة، الكوبونات، المحفظة، طرق الدفع والنتيجة النهائية تبقى server-authoritative.

Modular Monolith
Versioned REST API

الصورة المنطقية للمنصة

الـModular Monolith متعمد: Checkout يحتاج consistency بين inventory، slots، characters، wallet، coupons، payment وorders. نفصل الـdomains منطقيًا بدون تكلفة distributed transactions مبكرًا.

iOS / AndroidFlutter consumer apps
Responsive WebStorefront
Admin / OperationsWeb control plane
Kidzy Modular Commerce CoreIdentity · Catalog · Cart · Pricing · Gifting · Delivery · Reservations · Orders · Payments · Inventory · Procurement
MySQL 8.4Transactional data
Redis-compatibleCache · queues · short locks
Object Storage / CDNMedia
External ProvidersPayment · OTP · FCM · Meta

كل Domain يملك بياناته وقواعده

لا نسمح لـmodule أن يعدّل critical tables الخاصة بـmodule آخر بـad-hoc SQL. الحدود الواضحة هي التي تجعل النظام قابلًا للصيانة والتوسع.

ما لا يجب أن يقرره Flutter أو JavaScript Storefront

الـclient يقدم العرض، local validation وتحسين UX. لكنه لا يصبح مصدر الحقيقة في قرارات مالية أو تشغيلية حرجة.

!
Frontend checkbox ≠ feature implemented

إذا كانت واجهة الإدارة تعرض خيارًا لا تحترمه الـAPIs والـApp، أو كان هناك field بدون persistence أو audit عند الحاجة، فالميزة غير مكتملة.

القرارات التقنية المقفولة

الـstack يدعم التطبيق، الويب والإدارة فوق نفس المصدر التجاري، مع queues، caching، observability وversioned APIs.

Canonical catalog

لا توجد English Product وArabic Product ككيانين مختلفين.

#
Product #1842

SKU واحد · brand/category relations · age model · stock · price · delivery profile · translations AR/EN.

Historical order snapshots

الطلب القديم لا يعيد قراءة الاسم أو السعر الحالي للمنتج.

Immutable commercial history

Order line يحتفظ بالاسم، السعر، الخصم، الخدمات، الرسوم والحقائق اللازمة وقت الشراء.