NestJS

بناء التطبيق حول modules تمثل قدرات العمل، لا حول مجلدات عشوائية.

إبقاء controllers مركزة على نقل HTTP بينما تحمل services سلوك المجال الفعلي.

استخدام dependency injection لجعل orchestration والاختبار واستبدال الاعتماديات أمورا قابلة للتوقع.

معاملة framework كأداة لرسم حدود النظام، لا كطبقة شكلية فوق كود غير منظم.

تقديم APIs تخدم مواقع عامة، وتطبيقات موبايل، ولوحات admin، وسير عمل داخلي.

الحفاظ على اتساق المصادقة، والصلاحيات، وقواعد العمل، والآثار الجانبية عبر كل نقاط الدخول.

تصميم modules بحيث لا يتحول نمو المنتج تلقائيا إلى service ضخم باعتماديات مخفية.

تهيئة الباكند لاحقا للإشعارات، وaudit logs، والفوترة، والوسائط، والدعم، والتحليلات.

تعريف حدود modules بلغة العمل: users أو auth أو billing أو chat أو claims أو wallet أو gamification.

كشف services عامة وواضحة بدلا من السماح لكل module بالوصول المباشر إلى كل module آخر.

فصل facades وreaders وorchestrators وdomain services عندما تبرر درجة التعقيد ذلك.

تجنب services ضخمة تتحقق من المدخلات، وتشغل queries، وتطلق events، وتنسق responses في الوقت نفسه.

استخدام DTOs لتعريف شكل المدخلات العامة المقبول بدلا من الثقة في request bodies الخام.

الحفاظ على اتساق أوصاف Swagger والأمثلة وأكواد الحالة وdecorators الخاصة بالتحقق.

توثيق responses الخاصة بالأخطاء والحالات الحدية حتى لا يضطر مستهلكو API إلى التخمين.

استخدام أدوات تحقق OpenAPI مثل Schemathesis لاكتشاف الانحراف بين التوثيق والتنفيذ.

استخدام guards لفرض المصادقة، والأدوار، والملكية، وقواعد الوصول الحساسة بوضوح.

التحقق من كل المدخلات العامة وعدم إضعاف DTOs فقط لتمرير tests أو demos.

إبقاء أخطاء العمل ثابتة، ومقروءة، وآمنة عند عرضها عبر APIs عامة.

حماية التدفقات الحساسة مثل login وrefresh tokens ووصول admin والفوترة والuploads وتغييرات الحساب.

استخدام معاملات Prisma في workflows التي يجب أن تعتمد عدة تغييرات مرتبطة معا.

إبقاء idempotency keys ومراجع المصدر وunique constraints قريبة من قاعدة العمل التي تحميها.

تجنب إخفاء قرارات التخزين المهمة خلف helpers عامة تجعل النية أصعب في المراجعة.

التحقق من شكل queries، والحقول المختارة، والترتيب، والفلاتر، وفروع المعاملة عبر اختبارات مركزة.

إبقاء WebSocket gateways خفيفة ونقل سلوك المجال إلى services أو orchestrators.

فصل response المباشر للـ API عن الآثار الجانبية مثل الإشعارات، والإيميلات، والتحليلات، وaudit logs.

تصميم أسماء events وpayloads وقواعد التسليم كعقود، لا كتفاصيل تنفيذ عابرة.

جعل سلوك realtime قابلا للملاحظة بما يكفي لتصحيح chat وpresence والدعم وتدفقات admin.

كتابة unit tests لقرارات services، ومسارات exceptions، وguards، وDTOs، وفروع fallback.

استخدام integration وE2E tests لتعاون modules الحقيقي، وسلوك قاعدة البيانات، وتدفقات HTTP العامة.

تشغيل Schemathesis على عقد OpenAPI، وk6 لإشارات الأداء، وOWASP ZAP على الأسطح المكشوفة.

استخدام Stryker mutation testing لإثبات أن assertions تكشف الانحدارات بدلا من مجرد تنفيذ الكود.

يمكن للـ codebase استيعاب قواعد منتج جديدة دون إعادة كتابة modules غير مرتبطة.

تبقى قواعد الأمان، والتحقق، والمعاملات، والوصول قوية حتى عندما تفشل الاختبارات.

يعرض المستودع scripts واضحة لـ typecheck وlint وbuild وtests وcontracts وsmoke checks وmutation testing.

يمكن لمطور جديد فهم حدود modules، وتشغيل سلسلة الجودة، وتعديل feature واحدة دون كسر المنصة.