حوكمة مخطط GraphQL: مراجعة التغييرات الكاسرة قبل الإصدار

باختصار

حوكمة مخطط GraphQL هي انضباط الإصدار الذي يحافظ على فائدة المخطط أثناء تغيره. قبل كل إصدار، صنّف تعديلات المخطط، واختبر عمليات العميل التمثيلية، وانشر مسار الإهمال، وتحقق من الوثائق. مساحة عمل مشتركة مثل Apidog توفر للتصميم والطلبات والاختبارات والوثائق وأعمال المحاكاة موطنًا واحدًا.

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

مقدمة

تحافظ حوكمة مخطط GraphQL على إصدارات API من كسر تطبيقات الجوال وعملاء الويب والتكاملات والخدمات الداخلية دون سابق إنذار. يجعل GraphQL استعلامات العميل مرنة، لكن كل حقل ووسيطة وقيمة enum وقاعدة قابلية null وكائن إدخال يصبح جزءًا من العقد بمجرد أن يعتمد عليه العميل.

يتغير هذا العقد كثيرًا. يعيد فريق المنتج تسمية displayName. يجعل فريق الواجهة الخلفية إدخالًا اختياريًا إلزاميًا. تزيل خدمة الفوترة قيمة enum. قد يبدو كل تعديل غير ضار في محرر المخطط بينما يبطل عملية محفوظة في الإنتاج.

يصف مواصفات GraphQL نظام أنواع GraphQL وقواعد التحقق ومخاوف تطور المخطط. يمنح الفرق اللغة المشتركة. توفر الحوكمة عملية الإصدار: من يراجع التغيير، وكيف تقيّم الفرق تأثير العميل، وكيف تختبره، وكيف تتقاعد الحقول القديمة دون انقطاع مفاجئ.

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

ما هي حوكمة مخطط GraphQL؟

حوكمة مخطط GraphQL هي عملية قابلة للتكرار لمراجعة واختبار وتوثيق والموافقة على تغييرات المخطط قبل الإصدار. تحدد التعديلات الكاسرة للعميل، وتتطلب مسار ترحيل معتمدًا، وتبقي الملكية مرئية. الهدف هو تطور مخطط يمكن التنبؤ به: يحصل العملاء على الوقت والتعليمات للانتقال قبل اختفاء عقد قديم.

لا تعني الحوكمة تجميد المخطط. تتغير واجهة GraphQL API السليمة مع المنتج. تسمح العملية بتغييره بأمان.

تجيب سياسة الحوكمة المفيدة على خمسة أسئلة لكل طلب سحب أو مرشح إصدار:

1. ما الذي تغير في المخطط؟
2. أي التغييرات يمكن أن تجعل عملية عميل صالحة سابقًا تفشل؟
3. من يملك الحقول المتأثرة وترحيلات العميل؟
4. أي العمليات المحفوظة وفحوصات الاستجابة تثبت التوافق؟
5. متى يمكن إزالة حقل أو قيمة enum مهملة؟

تحوّل هذه الأسئلة طلبًا غامضًا لـ "مراجعة API" إلى دليل يمكن للمراجع فحصه.

لماذا يحتاج GraphQL إلى عملية إصدار صريحة

يؤلف عملاء GraphQL مجموعات التحديد الخاصة بهم. يمكن لعميلين استدعاء نفس جذر الاستعلام بينما يعتمدان على حقول وشظايا ومتغيرات وأسماء مستعارة مختلفة تمامًا. تساعد قياسات الخادم والاستعلامات المحفوظة ومعرفة فريق المستهلك، لكن لا شيء منها وحده يثبت أن التعديل آمن.

يمكن أن يمر التغيير أيضًا باختبار وحدة الخادم بينما يفشل العميل في وقت التحقق. إزالة حقل تجعل كل عملية تحده غير صالحة. إضافة حقل إدخال مطلوب يمكن أن تبطل العمليات التي تحذفه. تغيير enum يمكن أن يترك عميلًا مُنشأً أو فرع تبديل شامل غير قادر على التعامل مع استجابة الخادم. استبدال نوع حقل قابل لـ null بشكل مختلف يمكن أن يكسر التحليل أو افتراضات واجهة المستخدم.

يظهر نفس التوتر في عمل إدارة API. يجب أن تساعد منصة إدارة GraphQL API الفرق في الحفاظ على قرارات العقد والوثائق والتحقق قريبة من API. تجعل الحوكمة هذه القدرات مفيدة أثناء الإصدار بدلاً من بعد وقوع حادث.

صنّف تعديلات المخطط قبل أن تناقشها

ابدأ كل تغيير بتصنيف. لا تحتاج التسميات إلى أن تكون معقدة. إنها تحتاج إلى إنتاج مسار المراجعة الصحيح.

الجدول نقطة انطلاق. قد يظل التغيير المفترض أنه إضافي مهمًا. على سبيل المثال، يعتبر بعض العملاء المُنشأين أو مدققي الاستجابة الصارمين الحقول غير المعروفة مشكلة. تسمح إعدادات التحقق من الاستجابة في Apidog بخصائص كائن إضافية افتراضيًا. إذا كانت سياستك تحتاج إلى فحص للخصائص غير المتوقعة، اضبط additionalProperties على Deny لمخطط الاستجابة ذي الصلة أو غيّر إعداد المشروع عن قصد.

التغييرات التي يجب أن توقف الإصدار افتراضيًا

يجب أن تتطلب المراجعة موافقة صريحة عندما تتضمن أيًا مما يلي:

• إزالة حقل، وسيطة، حقل إدخال، طفرة، استعلام، تنفيذ واجهة، عضو اتحاد، أو قيمة enum.
• إعادة تسمية حقل بدلاً من إضافة بديل وإهمال الاسم القديم.
• جعل إدخال اختياري سابقًا إلزاميًا.
• تغيير نوع حقل، توقع قابلية null، تنسيق، سلوك التفويض، سلوك ترقيم الصفحات، أو عقد الخطأ.
• إعادة استخدام اسم حقل موجود لمعنى تجاري مختلف.
• تغيير قيمة افتراضية يحذفها العملاء عن قصد.

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

استخدم الإهمال كعقد ترحيل

يعمل الإهمال عندما يحتوي على مسار حقيقي للمضي قدمًا. "مهمل" بدون بديل أو مالك أو موعد نهائي أو ملاحظات ترحيل يؤجل ببساطة تغييرًا كاسرًا.

فكر في تنظيف اسم العميل. لا تعد تسمية الحقل في مكانه:

# Avoid removing fullName in the same release.
type Customer {
 fullName: String!
}

أضف البديل، واشرح السبب، ثم ادعم كلا الحقلين خلال النافذة المعلنة:

type Customer {
 displayName: String!
 fullName: String! @deprecated(reason: "Use displayName. Removal planned after client migration.")
}

يحتاج البديل أكثر من مجرد تعليق توضيحي في المخطط. أضفه إلى الوثائق، وحدّث عملاء الطرف الأول، وحدد المستهلكين ذوي القيمة العالية، وتتبع التبني. لا تزل الحقل القديم إلا بعد استيفاء معايير الخروج من الترحيل.

ابنِ سير عمل حوكمة مخطط GraphQL

يحتوي سير العمل القابل للتكرار على نقاط تفتيش. لا يعتمد على شخص واحد يتذكر كل تفاصيل العميل أثناء إصدار متسرع.

1. أنشئ مصدر حقيقة ومالكين مسمين

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

سجّل هذه التفاصيل إلى جانب تغيير المخطط:

• منطقة المخطط والفريق المالك.
• تصنيف التغيير.
• المستهلكون المعروفون باستخدام الحقل أو العملية المتأثرة.
• الحقل البديل أو تعليمات الترحيل.
• أقرب تاريخ للإزالة.
• الاختبارات التي تثبت نجاح الإصدار المرشح.

يمنع هذا السجل الحقل من أن يصبح منطقة سطح عامة مهجورة.

2. قارن مخطط المرشح وعيّن المخاطر

أنشئ أو راجع فرق المخطط بين الإصدار الحالي والمرشح. لا تتوقف عند فرق سطر بسطر. ترجم النتيجة إلى تأثير على العميل.

لكل نوع متغير، اسأل ما إذا كان استعلام موجود يمكن أن يصبح غير صالح، وما إذا كانت استجابة JSON موجودة يمكن أن يتغير شكلها، وما إذا كان السلوك يتغير دون تغيير نظام النوع. قواعد المصادقة مثال شائع. يمكن أن يظل المخطط متطابقًا بينما يبدأ حقل مرئي سابقًا في إرجاع خطأ تفويض أو null.

استخدم سجل تغيير قصير مثل هذا:

change: remove Customer.fullName
type: breaking
owner: customer-platform
replacement: Customer.displayName
deprecated_since: 2026-08-21
planned_removal: 2026-11-21
known_consumers:
 - ios-storefront
 - partner-portal
release_checks:
 - saved-operation-suite
 - client-migration-confirmations
 - published-release-notes

التواريخ أمثلة. يجب أن تحدد سياستك نافذة إهمال تتوافق مع وتيرة الإصدار وسرعة تحديث العميل والالتزامات التعاقدية.

3. اختبر العمليات الحقيقية، وليس فقط بناء جملة المخطط

يمكن أن يُحلّل المخطط ومع ذلك يكسر العميل. حافظ على مجموعة من العمليات التمثيلية لكل مستهلك رئيسي أو رحلة مستخدم. قم بتضمين الشظايا والمتغيرات وترقيم الصفحات وحدود الأذونات والأخطاء والحقول الاختيارية.

بالنسبة لمتجر، قد تتضمن المجموعة:

query ProductPage($sku: ID!, $first: Int!) {
 product(sku: $sku) {
 id
 displayName
 price {
 amount
 currency
 }
 relatedProducts(first: $first) {
 nodes {
 id
 displayName
 }
 }
 }
}

قم بتشغيل العملية مقابل البيئة المرشحة. أكّد حالة HTTP، وأخطاء GraphQL، وقيم الاستجابة المطلوبة، وتوقعات النوع، وقواعد العمل التي تهم العميل. استجابة بحالة HTTP 200 ومصفوفة errors ليست عملية GraphQL ناجحة للعديد من حالات الاستخدام.

استخدم تركيبات الطلبات التي تغطي حالات حافة حقيقية: قوائم فارغة، حقول اختيارية null، موارد محذوفة، رفض إذن، اختلافات اللغة، ومؤشرات قديمة. تصبح العمليات المحفوظة الدليل وراء قرار الإصدار.

4. اجعل الوثائق جزءًا من البوابة

تحتاج الوثائق إلى نفس تاريخ مراجعة المخطط. الحقل الموجود ولكن يفتقر إلى وصف أو أمثلة أو ملاحظات إذن أو إرشادات ترحيل يجبر فرق العملاء على هندسة النية عكسيًا.

لكل حقل أو إدخال متأثر، تحقق من:

• هل يشرح الوصف المعنى التجاري بدلاً من سلوك المحلل؟
• هل توقعات قابلية null والقيمة الافتراضية واضحة؟
• هل يذكر الحقل المهمل بديله؟
• هل تستخدم الأمثلة ذات الصلة الحقل الجديد؟
• هل يشرح سجل التغييرات الإجراء والجمهور وتاريخ الإزالة؟

هنا أيضًا تمنع الفرق المشكلة الشائعة لمخطط GraphQL الذي يعمل فقط عند توفر الاستبطان. يجب أن تكون المواد المرجعية المنشورة وملاحظات الإصدار قائمة بذاتها للعملاء الخارجيين والبيئات المقيدة.

5. أطلق، وراقب، وأزل بناءً على الدليل

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

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

استخدم Apidog لجعل المراجعة قابلة للتكرار

Apidog يوفر لفرق API مساحة عمل واحدة للتصميم والتصحيح والاختبار والوثائق والمحاكاة. بالنسبة لعملية حوكمة GraphQL، الهدف المفيد هو مسار مراجعة مشترك، وليس أداة منفصلة لكل خطوة إصدار.

في Apidog، أنشئ طلب GraphQL عبر Body > GraphQL، ثم استخدم Fetch Schema لتحميل المخطط. يستخدم محرر GraphQL المخطط الذي تم جلبه لاقتراحات الحقول والأنواع ويتحقق من الاستعلامات مقابله. اقرأ وثائق طلب GraphQL الرسمية قبل تكوين سير عمل الفريق.

يبدو إعداد الإصدار العملي كما يلي:

1. احفظ استعلامات وطفرات تمثيلية لكل تدفق حرج.
2. ضع متغيرات خاصة بالبيئة خارج الاستعلام بحيث يظل شكل العملية مستقرًا.
3. أضف تأكيدات للحالة، والرؤوس، وشكل استجابة JSON، والحقول المطلوبة، وenums، وسلوك الخطأ.
4. جمّع الفحوصات في مجموعة إصدار للبيئة المرشحة.
5. راجع الفحوصات الفاشلة مع فرق المخطط وسجل التغيير قبل الموافقة.
6. انشر الوثائق وملاحظات الترحيل من نفس عقد API المعتمد.

يتحقق التحقق من الاستجابة من الحالة والتنسيق والتوافق مع المخطط. تتضمن الفحوصات الموثقة الحقول المطلوبة والأنواع وقابلية null وقيم enum والنطاقات والأنماط لاستجابات JSON و XML. هذا يجعله مفيدًا لنصوص استجابة GraphQL لأن استجابات GraphQL تستخدم JSON. لا يحل محل أداة فرق مخطط GraphQL أو جرد المستهلك. استخدمه مع كليهما.

إذا كان فريقك يبدأ من اختبارات على مستوى الطلب، يمكن أن تساعد أدوات اختبار ومحاكاة GraphQL في تأطير طبقة الاختبار. تضيف الحوكمة سجل الإصدار والملكية وسياسة الإهمال حول تلك الاختبارات.

حمّل Apidog عندما تريد سير عمل التصميم والطلب والتحقق من الاستجابة والوثائق والمحاكاة في مساحة عمل واحدة. احتفظ بسياسة الحوكمة في مستودعك واستخدم مساحة العمل لإعطاء كل مراجعة إصدار دليل اختبار ملموس.

تقنيات متقدمة لواجهات GraphQL الأكبر

حدد طبقات المستهلك

ليس كل عميل يحمل نفس مخاطر الإصدار. صنّف المستهلكين حسب التأثير وسرعة الترقية:

تمنع الطبقات تجربة داخلية صغيرة من فرض نفس عبء الإصدار كتدفق دفع. كما تمنع تكاملًا خارجيًا حرجًا من أن يُعامل كاستعلام غير متتبع.

تتبع تغييرات السلوك خارج المخطط

لا يمكن لفروق المخطط اكتشاف كل تغيير في العقد. أضف أسئلة مراجعة لـ:

• التفويض والوصول على مستوى الحقل.
• ترتيب ترقيم الصفحات، وعمر المؤشر، وحدود حجم الصفحة.
• سلوك التخزين المؤقت وتوقيت الإبطال.
• ملحقات الخطأ ورسائل الخطأ المرئية للمستخدم.
• سلوك حد المعدل وإرشادات إعادة المحاولة.
• أداء المحلل الذي يحول عملية صالحة إلى عملية غير موثوقة.

اكتب اختبارًا مستهدفًا لكل تغيير سلوكي مخطط. يمنع هذا تسمية سطحية "لا يوجد تغيير كاسر في المخطط" من أن تصبح تمرير إصدار.

تعامل مع حدود الاتحاد كحدود عقد

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

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

حدد مسار استثناء

تحدث الإزالات العاجلة عندما يكشف حقل عن بيانات، أو يخلق مشكلة أمنية، أو يسبب ضررًا تشغيليًا خطيرًا. تحتاج الحوكمة إلى مسار استثناء حتى لا تتخطى الفرق الوثائق والاختبار تحت الضغط.

يجب أن يذكر سجل الاستثناء المخاطر، والمالك الموافق، والمستهلكين المتأثرين، والتخفيف، وخطة المتابعة. أبلغ المستهلكين مباشرة عندما لا تكون نافذة الإهمال العادية ممكنة. ثم أضف اختبار انحدار حتى لا يعود نفس الخطأ.

البدائل والحدود

يمكن أن يساعد سجل المخطط، أو بوابة الاتحاد، أو عميل مُنشأ، أو فحص فرق المخطط في CI. لا شيء منها يحل محل العملية الكاملة.

اختر أصغر مجموعة تنتج أدلة موثوقة لواجهة API الخاصة بك. إذا كان فريقك يقرر ما إذا كان GraphQL يناسب خدمة جديدة، فقارن نموذج الاستعلام المدفوع بالعميل مع REST و gRPC في REST vs GraphQL vs gRPC. اختيار البروتوكول وحوكمة الإصدار قراران منفصلان. لا يزال كل عقد عام يحتاج إلى كليهما.

حالات استخدام واقعية

تطبيق جوال يحتاج إلى حقل ملف شخصي معاد تسميته

يريد فريق الملف الشخصي استبدال fullName بـ displayName لأن حسابات المؤسسة تستخدم نموذج تسمية مختلف. مسار الحوكمة ليس التزام إعادة تسمية يتبعه إصدار.

أضف displayName، واحتفظ بـ fullName مع سبب إهمال، وحدّث استعلام الجوال، واختبر كلا الحقلين أثناء الانتقال، واجمع بيانات التبني حسب إصدار التطبيق. لا تزل fullName إلا بعد أن لا تعتمد عليه إصدارات التطبيق المدعومة أو تنتهي نافذة الدعم المنشورة.

طفرة الدفع تحصل على متطلب إدخال جديد

يريد فريق الدفع أن يصبح CheckoutInput.taxRegion إلزاميًا. إصدارات التطبيق الحالية تحذف القيمة. جعل الإدخال إلزاميًا على الفور يمكن أن يجعل عمليات الدفع الصالحة تفشل في التحقق.

أبقِ الإدخال اختياريًا أثناء الترحيل، وحدد سلوك الرجوع الاحتياطي للخادم، وانشر المتطلب الجديد، وحدّث العملاء، وأضف حالات اختبار لأشكال الطلبات القديمة والجديدة. بعد انتقال العملاء، اجعل القاعدة المطلوبة في إصدار كاسر مخطط.

شريك يرى تغييرًا غير موثق في حقل

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

يسجل الفريق المالك الشريك كمستهلك من الطبقة 1، ويضيف حقلًا بديلًا بدلاً من تغيير الحقل القديم في مكانه، ويمنح الشريك بيئة اختبار، ويتحقق من عملية شريك محفوظة قبل الإزالة. الوثائق والاتصال المباشر جزء من دليل الإصدار.

ابدأ بقائمة تحقق واحدة للإصدار

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

ثم اجعل قائمة التحقق عادة إصدار. يمكن لـ Apidog الاحتفاظ بالطلبات والتحقق من الاستجابة والوثائق وسيناريوهات المحاكاة وأدلة الاختبار معًا بينما يظل مستودعك مصدر سياسة الحوكمة. النتيجة هي عمليات تراجع طارئة أقل وتوقعات أوضح لكل مستهلك API.

الأسئلة الشائعة

ما الذي يعتبر تغييرًا كاسرًا في مخطط GraphQL؟

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

هل إضافة حقل GraphQL آمنة دائمًا؟

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

كم من الوقت يجب أن يظل حقل GraphQL مهملًا؟

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

هل يمكن لاستبطان GraphQL أن يحل محل الوثائق؟

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

كيف تختبر تغييرات GraphQL الكاسرة قبل الإنتاج؟

قم بتشغيل فرق المخطط، ثم نفّذ الاستعلامات والطفرات التمثيلية المحفوظة مقابل البيئة المرشحة. أكّد أخطاء GraphQL والبيانات المطلوبة والأنواع وقيم enum وسلوك null والأذونات والنتائج التجارية. قم بتضمين عمليات العميل عالية التأثير بدلاً من اختبارات الدخان العامة فقط.

هل يلتقط التحقق من الاستجابة كل انحدار في GraphQL؟

لا. يلتقط عقد الاستجابة الموثق الذي تختار التحقق منه. لا يحدد كل مستهلك، أو يقارن مخططات GraphQL الكاملة، أو يكتشف تغييرات السلوك غير الموثقة بنفسه. اقرن التحقق من الاستجابة باختبارات العمليات ومراجعة المخطط والملكية وعملية الإهمال.