عبدالله سنكر: هيكلة مشروع Flutter كبير بالطبقات والمجلدات

أول شهرين في أي مشروع Flutter كلها حلوة: ملف main.dart، ومجلد screens، وكل شي يشتغل. بعدها يكبر التطبيق، وتفتح شاشة الطلبات فتلقى فيها ألف سطر: استدعاء للخادم، وتحويل JSON، وحساب خصم، وتصميم بطاقة، كلها في ملف واحد. أي تعديل صغير يكسر شي بعيد، والمطوّر الجديد يحتاج أسبوعاً عشان يعرف وين يكتب. عبدالله سنكر يبني تطبيقاته بـ Flutter و Dart، وهذي الطريقة اللي يرتّب فيها المشروع الكبير من البداية، خطوة بعد خطوة، مع المواضع اللي يقول فيها بصراحة: لا تبالغ.

الخطوة الأولى: قسّم حسب الميزة، مو حسب نوع الملف

فيه مدرستين في ترتيب المجلدات. الأولى تجمع الملفات حسب نوعها: مجلد للشاشات، ومجلد للنماذج، ومجلد للخدمات. هذي مريحة في تطبيق من خمس شاشات، لكنها تتعبك لما يكبر المشروع، لأن تعديل ميزة وحدة مثل «الطلبات» يخلّيك تتنقل بين خمسة مجلدات متباعدة. المدرسة الثانية تجمع الملفات حسب الميزة: مجلد للطلبات، ومجلد لتسجيل الدخول، ومجلد للملف الشخصي، وكل مجلد فيه كل اللي يخص ميزته. تفتح المجلد فتشوف الميزة كاملة، ولو قررت تشيل الميزة تشيل المجلد. في المشاريع الكبيرة هذا الفرق يوفّر ساعات كل أسبوع.

الخطوة الثانية: ثلاث طبقات داخل كل ميزة

داخل مجلد الميزة، الكود ينقسم حسب المسؤولية. كل طبقة لها سؤال وحيد تجاوب عليه:

• طبقة البيانات (data): من وين تجي البيانات وكيف ترجع؟ هنا مصادر البيانات اللي تكلّم الخادم أو القاعدة المحلية، ونماذج النقل اللي تعرف شكل JSON بالضبط، وتنفيذ المستودع.
• طبقة المنطق (domain): وش قواعد العمل؟ هنا الكيانات بلغة النشاط مثل «طلب» و«عميل»، وواجهة المستودع المجرّدة، والقواعد مثل حساب الخصم أو شروط إلغاء الطلب. هذي الطبقة ما تستورد Flutter ولا حزمة الشبكة أبداً.
• طبقة العرض (presentation): وش يشوف المستخدم وكيف يتفاعل؟ هنا الشاشات والويدجتات ووحدات إدارة الحالة. تعرض وتستقبل الضغطات، وما تدري من وين جت البيانات.

القاعدة الذهبية هي اتجاه الاعتماد: طبقة العرض تعتمد على المنطق، وطبقة البيانات تنفّذ ما يطلبه المنطق، والمنطق ما يعرف أحداً. وش تكسب؟ لو انتقلت يوماً من خادم REST إلى Firebase، تتغير طبقة البيانات بس. ولو تبي تختبر حساب الخصم، تختبره كدالة Dart عادية بدون محاكي ولا شبكة.

ووين تقعد وحدة إدارة الحالة؟ في طبقة العرض، لكنها هي الوسيط الوحيد بين الشاشة والمستودع. الشاشة تقول لها «المستخدم ضغط تحديث»، وهي تطلب من المستودع، وترجع للشاشة حالة واضحة: جاري التحميل، أو قائمة، أو قائمة فاضية، أو خطأ برسالة. لما تشوف ويدجت يستدعي الخادم مباشرة من داخل onPressed، فهذي أول علامة إن الطبقات بدأت تذوب.

الخطوة الثالثة: شكل المجلدات على أرض الواقع

• lib/core: اللي يخدم كل الميزات، مثل عميل الشبكة وإعداداته، وأنواع الأخطاء الموحّدة، والثيم، والتوجيه بين الشاشات.
• lib/features/orders/data: ملفات مثل orders_api.dart و order_dto.dart و orders_repository_impl.dart.
• lib/features/orders/domain: الكيان order.dart، وواجهة orders_repository.dart بدون تنفيذ، وقواعد الطلبات.
• lib/features/orders/presentation: شاشة orders_screen.dart، ومجلد widgets لبطاقات الطلب، وملف وحدة الحالة.
• lib/shared/widgets: الأزرار والحقول والبطاقات اللي تتكرر في أكثر من ميزة، بعد ما تتكرر فعلاً مو قبل.
• lib/l10n: ملفات arb للنصوص، عشان ما يبقى نص عربي مكتوب مباشرة داخل ويدجت.
• test: نفس شجرة lib بالضبط، فاختبار order_dto يلقاه أي أحد في المكان المتوقع.

وفرّق بين نموذج النقل والكيان. نموذج النقل يعكس الخادم بأسمائه وأنواعه، حتى لو كان التاريخ نصاً والحالة رقماً. والكيان يعكس العمل: تاريخ حقيقي، وحالة من قائمة محددة. التحويل بينهما يصير في مكان واحد داخل طبقة البيانات، فلو غيّر الخادم اسم حقل، تعدّل سطراً واحداً بدل ما تطارد الاسم في عشرين شاشة.

الخطوة الرابعة: قرارات تنحسم مرة وحدة للمشروع كله

• إدارة الحالة: Riverpod أو Bloc أو غيرهما. الاختيار نفسه أقل أهمية من إن المشروع كله يمشي على أداة وحدة بأسلوب واحد.
• التوجيه: مسارات بأسماء ثابتة في ملف واحد عبر go_router أو ما يشابهه، وهذا يسهّل الروابط العميقة والإشعارات اللي تفتح شاشة محددة.
• حقن الاعتماديات: الشاشة تستلم المستودع جاهزاً، ما تصنعه بنفسها، فتقدر تبدله بنسخة وهمية وقت الاختبار.
• البيئات: نسخة تطوير ونسخة إنتاج بقيم تُمرَّر وقت البناء عبر dart-define أو flavors، بدل تعديل رابط الخادم يدوياً قبل كل نشر.
• الأخطاء: نوع موحّد للفشل، مثل انقطاع الاتصال أو انتهاء الجلسة أو رفض التحقق، والواجهة تترجمه لرسالة يفهمها المستخدم.

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

متى تقول «لا» للهيكلة الثقيلة

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

في منصة أزهل الرقمية، الهيكلة تنقاس بسؤال واحد: لو جاء مطوّر جديد بكرة، كم يحتاج عشان يضيف ميزة صغيرة بدون ما يكسر شي؟ إذا الجواب ساعات، فالهيكلة شغّالة. وإذا كان أياماً، فالمشكلة غالباً مو في Flutter، في ترتيب الكود. وترتيب الكود قرار تاخذه مرة في البداية، أو تدفع ثمنه كل أسبوع بعدين، في كل ميزة جديدة وكل إصلاح وكل مطوّر ينضم للفريق.