دفتري

لماذا بدأ؟

بدأ المشروع كفكرة عملية من واقع السوق: صاحب بقالة أو محل صغير يدير ديون زبائنه في دفتر ورقي أو ذاكرته، ويضيع عليه المبلغ أو يُنسى من سدّد ومن لم يسدّد. السؤال الذي ولّد المشروع كان بسيطًا: كيف نُحوّل «دفتر الجرورة» إلى نظام رقمي يعمل حتى بدون إنترنت؟

من هنا انطلق دفتر الجرورة — تطبيق Flutter مع Laravel API لإدارة العملاء والديون والتذكيرات عبر واتساب. ثم توسّع السؤال: لماذا يقتصر الحل على الديون فقط، بينما التاجر يحتاج مخزونًا ونقطة بيع وطلبات أونلاين وتوصيلًا واشتراكاتًا؟ فتحوّلت الرؤية إلى منصّة SaaS متعددة الأنظمة تبدأ بـ دفتري متاجر (Daftri Shop) وتتوسّع لاحقًا لأنظمة رأسية أخرى (مطاعم… إلخ).

المشكلة

التاجر الصغير في السودان والعالم العربي يعيش مشكلتين معًا:

تشتّت الأدوات: دفتر للديون، تطبيق آخر للمخزون، ورقة للفواتير — لا يوجد نظام واحد يجمع التجارة اليومية. انقطاع الإنترنت: معظم الحلول السحابية تتوقف عند ضعف الشبكة، بينما المحل يجب أن يستمر في البيع والتسجيل. المشكلة الحقيقية ليست «تطبيق ديون» فقط، بل غياب منصّة متكاملة، عربية، Offline-first، تخدم التاجر والعميل والمندوب والمسوّق من مكان واحد.

لمن؟

التاجر (صاحب المحل) POS، مخزون، عملاء، ديون، فواتير، طلبات أونلاين العميل تصفّح المحال وطلب أونلاين ضمن منطقته مندوب التوصيل استلام وتوصيل الطلبات عبر شبكة موحّدة المسوّق إعادة بيع اشتراكات بخصم متدرّج مشغّل المنصّة (الإدارة) إدارة الأنظمة، الباقات، الحسابات، الاعتمادات

ماذا بنيت حتى الآن؟

المشروع في مرحلة انتقال معماري: من نظام ديون بسيط إلى منصّة متعددة الأنظمة.

ما كان موجودًا (الجيل الأول)

• تطبيق Flutter Offline-first لإدارة العملاء والديون والتذكيرات.
• Laravel API + لوحة Livewire للإدارة.
• مزامنة، واتساب، اشتراكات، تقارير.

ما بُني حديثًا (الجيل الثاني — Backend)

تم تنفيذ معظم نواة المنصّة كـ Modular Monolith:

• النواة : وحدات Laravel (Core + DaftriShop)، قواعد بيانات هجينة (daftri_core + daftri_shop)، System Resolver، مفاتيح ULID.
• الهوية الموحّدة : حساب مركزي + ملفات أدوار + Sanctum.
• الجغرافيا : دول/ولايات/مدن + عزل إقليمي.
• الاشتراكات والخصائص : باقات + بوّابة entitlements.
• دفتري متاجر: مخزون، POS، عملاء/ديون، مشتريات، فواتير، إشعارات بنكية، تقارير، تحليلات AI.
• الدفع ، الرسائل/واتساب ، المزامنة ونبضة الترخيص 72 ساعة (021).
• اختبار Pest يغطي معظم هذه الوحدات (المنصّة قيد التطوير النشط).

ما لم يُكتمل بعد

• خمسة تطبيقات Flutter الجديدة (التاجر، العملاء، المندوب، المسوّق، الإدارة) — مواصفاتها جاهزة، التنفيذ لم يبدأ.
• الحِزَم المشتركة Dart — design system، API client، offline/sync.
• شبكة التوصيل - ومتجر العملاء - والمسوّقون — مواصفات/مهام جاهزة، تنفيذ جزئي أو معلّق.

كيف أفكر في الحل؟

• 5 تطبيقات Flutter
• Laravel Modular Monolith
• REST API + X-Daftri-System
• Contracts + Events
• الإدارة - أونلاين فقط
• التاجر - Offline-first
• العملاء
• المندوب
• المسوّق
• Core - daftri_core
• DaftriShop - daftri_shop

المبادئ التي تحكم كل قرار:

• API-First: Laravel API .
• Modular Monolith: مشروع واحد، وحدات منفصلة، قواعد بيانات منفصلة — بدون ميكروسيرفس مبكرًا.
• Offline-First: كل شيء يُسجَّل محليًا أولًا، ثم يُزامَن؛ نبضة ترخيص 72 ساعة.
• عزل صارم: نظام / مستأجر / منطقة — على مستوى الخادم لا الواجهة فقط.
• البساطة والتدرّج: نبدأ بـ دفتري متاجر، نُضيف أنظمة رأسية لاحقًا دون كسر النواة.
• مواصفات قبل كود: منهجية spec-kit (constitution → specify → plan → tasks → implement).

التقنيات المستخدمة

Backend

• Laravel 13
• PHP 8.4
• nwidart/laravel-modules
• Sanctum 4
• spatie/permission

قواعد البيانات

• MySQL (متعدد الاتصالات) + SQLite للاختبارات

الاختبارات

• Pest 4 + arch tests

Mobile/Desktop

• Flutter (تطبيق ديون حالي + 5 تطبيقات مخطّطة)
• Offline
• SQLite محلي + Sync Queue

الدفع

• PayPal
• برافو (مفاتيح مشفّرة لكل تاجر)

الرسائل

• واتساب عبر WaSenderAPI

الذكاء الاصطناعي

• مساعد تحليلات بمؤشّرات مقيّدة + kill switch
• DeepSeek

الحالة الحالية

• قيد البناء — مرحلة انتقالية

ما تعلمته

• المواصفات قبل الكود توفّر شهورًا: كتابة constitution.md و22 spec قبل التنفيذ منعت الانحراف المعماري.
• Modular Monolith أفضل من Microservices مبكرًا: عزل قواعد البيانات + عقود بين الوحدات يحقّق الفصل دون تعقيد النشر.
• Offline-first قرار منتج لا تقني: في أسواق ضعيفة الشبكة، المزامنة ونبضة الترخيص جزء من تجربة المستخدم لا ميزة إضافية.
• ULID ضروري للمنصّات المتعددة: يدعم توليد معرفات offline وتجاوز قيود FK بين قواعد منفصلة.
• إعادة التأطير مكلفة لكن ضرورية: الانتقال من «تطبيق ديون» إلى «منصّة» يستلزم إعادة بناء لا ترقية تدريجية فقط.

ما القادم؟

• الحِزَم المشتركة Dart: design system + API client + auth + offline/sync (أساس كل التطبيقات).
• تطبيق التاجر: POS + مخزون + عملاء + مزامنة (أول تطبيق Flutter جديد على المنصّة).
• متجر العملاء: كتالوج + طلب أونلاين + تطبيق العملاء.
• شبكة التوصيل: مناديب + إسناد جغرافي.
• تطبيق الإدارة: لوحة موحّدة بمُبدِّل أنظمة.
• المسوّقون (تقارير متقدّمة + AI) لاحقًا.