NestJS — Node.js للمؤسسات

أنماط معماريّة التطبيق

17 دقيقة الدرس 19 من 30

أنماط معماريّة التطبيق

يمنحك NestJS اللبنات؛ والمعماريّة هي كيفية ترتيبها مع نموّ التطبيق. مشروع صغير يكفيه الهيكل الافتراضي، لكنّ الكبير يستفيد من طبقات وحدود واضحة. يستعرض هذا الدرس الأنماط التي تُبقي قواعد كود NestJS الكبيرة سهلة الصيانة.

الافتراضي: المعماريّة الطبقيّة

الهيكل الذي يشجّعه NestJS جاهزًا تصميم طبقي (متعدّد الطبقات)، حيث لكل طبقة مسؤولية واحدة وتعتمد فقط على الطبقة تحتها:

Controller   ->  يعالج HTTP، يتحقّق من المدخل، يُعيد الاستجابات
Service      ->  منطق العمل وقواعده
Repository   ->  الوصول إلى البيانات (استعلامات قاعدة البيانات)
Entity/Model ->  شكل بياناتك

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

الطبقيّة تتعلّق باتّجاه التبعية. تعتمد الطبقات الأعلى على الأدنى، لا العكس أبدًا. وهذا يُبقي منطق العمل مستقلًّا عن كيفية تسليم البيانات (HTTP اليوم، GraphQL غدًا) أو تخزينها.

التنظيم النمطي (القائم على الميزة)

ضمن تلك الطبقات، نظّم حسب الميزة لا النوع. كل وحدة ميزة شريحة مكتفية ذاتيًا:

src/
  users/
    users.controller.ts
    users.service.ts
    users.repository.ts
    dto/
    entities/
    users.module.ts
  orders/
    ... الهيكل نفسه
  shared/        # أدوات عابرة للميزات

هذا يجعل الميزات سهلة الإيجاد، سهلة الاختبار منفردةً، وسهلة الاستخراج إلى خدمة مصغّرة لاحقًا إن لزم.

المعماريّة النظيفة / السداسيّة

للمجالات المعقّدة، تمضي الفِرَق أبعد بالمعماريّة النظيفة: يقع مجال العمل في المركز ولا يعرف شيئًا عن الأُطر أو قواعد البيانات. تعتمد الطبقات الخارجية (المتحكّمات والمستودعات) إلى الداخل على تجريدات، لا العكس أبدًا:

المجال (Domain) — الكيانات وقواعد العمل، نقيّة وخالية من الأُطر.
التطبيق (Application) — حالات الاستخدام التي تُنسّق المجال.
البنية التحتية (Infrastructure) — قاعدة البيانات وHTTP والخدمات الخارجية (التفاصيل القابلة للاستبدال).

يجعل حقن تبعيات NestJS هذا طبيعيًا: تعتمد الخدمة على واجهة (رمز)، وتربط تطبيق قاعدة البيانات الملموس عبر مزوّد مخصّص — فلا يستورد المجال الـ ORM أبدًا.

طابِق النمط مع المشكلة. تؤتي المعماريّة النظيفة ثمارها للأنظمة الكبيرة طويلة العمر كثيفة العمل. أمّا لواجهة CRUD صغيرة فهي مبالغة — الهيكل الطبقي + النمطي الافتراضي هو القدر الصحيح من المعماريّة.

إرشادات عمليّة

أبقِ المتحكّمات نحيلة: تحقّق، فوّض، أعِد.
ضع منطق العمل في الخدمات؛ وضع الوصول للبيانات خلف مستودع.
نظّم حسب وحدة الميزة؛ وصدّر فقط ما تحتاجه الوحدات الأخرى.
اعتمد على التجريدات (رموز/واجهات) لما قد تستبدله.
لا تُفرِط في الهندسة — أضِف الطبقات حين يتطلّبها التعقيد، لا قبله.

المعماريّة المبكرة ضارّة كغيابها. تغليف واجهة بثلاث نقاط نهاية في خمس طبقات تجريد يُبطئ الجميع. ابدأ بسيطًا؛ وأدخِل البنية حين يظهر ألم عدم وجودها.

الخلاصة

يفترض NestJS معماريّة طبقيّة (متحكّم ← خدمة ← مستودع) منظّمة في وحدات ميزات. ومع نموّ التعقيد، تُبقي المعماريّة النظيفة/السداسيّة مجال العمل مستقلًّا عن الأُطر وقواعد البيانات، وهو ما يدعمه حقن تبعيات NestJS طبيعيًا عبر رموز الواجهات والمزوّدات المخصّصة. اختر أخفّ هيكل يناسب المشكلة. بهذا تكتمل المرحلة الرابعة — صارت تطبيقاتك جيدة الإعداد والهيكلة. تاليًا: طبقة البيانات.