اختبار قابلية التراجع
متاح أيضًا بـ28 لغة
English · Español · 日本語 · Português (Brasil) · Français · Deutsch · Italiano · 한국어 · 简体中文 · Português (Portugal) · 繁體中文 · Bahasa Indonesia · Türkçe · Polski · Tiếng Việt · ไทย · Nederlands · עברית · Українська · हिन्दी · Русский · Svenska · Dansk · Norsk bokmål · Suomi · Español (México) · Français (Canada) · Deutsch (Schweiz)
الوحدة 3 من 7 في فصل التفكير كمعماري بيانات، الفصل الأول من دورة Data Architect. كل وحدة قائمة بذاتها. السابق: نموذج البيانات هو الهيكل العظمي · التالي: المعمارية هي فن المفاضلة
السؤال الذي تجيب عنه هذه الوحدة: كيف تميّز القرار المعماري من القرار العادي؟
يتخذ المعماريون قرارات كثيرة.
لكن ليس كل قرار قرارًا معماريًا.
هذا تمييز مهم. إذا عاملنا كل قرار على أنه معمارية، فسنقضي وقتنا كله في الجدال حول أشياء يسهل تغييرها نسبيًا. وإذا لم ندرك القرارات المعمارية حقًا، فقد نتخذ اليوم قرارًا في خمس دقائق يستغرق فكّه خمس سنوات.
إذن كيف نعرف الفرق؟
أحب أن أطرح سؤالًا بسيطًا:
ما مدى صعوبة التراجع عن هذا القرار لاحقًا؟
أسمّي هذا اختبار قابلية التراجع (Reversibility Test).
كلما كان التراجع عن الشيء أصعب، وكلما زادت الأشياء الأخرى التي ستعتمد عليه، استحق اهتمامًا معماريًا أكبر.
بعض القرارات رخيصة التغيير
Section titled “بعض القرارات رخيصة التغيير ”لنبدأ بشيء بسيط.
نسمّي حقلًا Customer Category (فئة العميل). وبعد ستة أشهر، يقرر فريق الأعمال أن الجميع يسمّونه في الحقيقة Customer Segment (شريحة العميل). فنغيّر التسمية الظاهرة (label). قد تكون هناك بعض الوثائق التي يجب تحديثها وقليل من تدريب المستخدمين، لكن هذا ليس حدثًا معماريًا كبيرًا. ومع ذلك سنضطر إلى التعايش مع اسم API الأصلي، لأن تغييره له عواقب أكبر بكثير. لذلك قد يعني هذا مجرد التعامل مع تغيير في التسمية، والالتباس الذي قد يصاحبه.
اتخذنا قرارًا. غيّرنا رأينا. ومضينا قدمًا.
والآن قارن ذلك بقرار مختلف.
ننشئ معرّفًا للعملاء. نقرر ماذا يعني، وما الصيغة التي يستخدمها، وأي نظام يُنشئه. ثم ننشره.
تستخدمه Salesforce. ويستخدمه مستودع البيانات. وتستخدمه منصة التكامل. وتستخدمه بوابة العملاء. وتبدأ خمسة تطبيقات أخرى في تخزينه. وتستخدمه التقارير وخطوط نقل البيانات. وربما يراه العملاء في النهاية.
وبعد ثلاث سنوات، يقول أحدهم:
ربما ما كان ينبغي أن نصمم المعرّف بهذه الطريقة.
هذه محادثة مختلفة تمامًا.
الفرق ليس أن أحد القرارين أكثر تقنية من الآخر.
الفرق هو قابلية التراجع.
إليك كيف يمكن أن يحدث ذلك. لنفترض أن العمل كان يبني مفاتيحه من جزء من اسم العميل مع رقم. ينجح ذلك لسنوات، لأن أحدًا لم يضطر قط إلى تغيير اسم. ثم بعد سنة أو أكثر، يتغير اسم فعلًا، وفجأة لا تعود المفاتيح مطابقة للنمط الذي تتوقعه بقية البيانات. وهذا أحد الأسباب التي تجعل المفاتيح لا ينبغي أن تحمل أي معنى في ذاتها.
المعمارية تصنع الجاذبية
Section titled “المعمارية تصنع الجاذبية ”يميل القرار المعماري إلى أن تتراكم الأشياء حوله. أفكر في ذلك على أنه جاذبية.
اختر نموذج كائنات، وستُبنى الأتمتة حوله.
اختر مفتاحًا، وستبدأ أنظمة أخرى في تخزينه.
اختر مكان البيانات الرئيسية، وستبدأ عمليات التكامل في التدفق نحوه ومنه.
اختر نموذج مشاركة، وستبدأ عمليات العمل في الاعتماد على من يستطيع رؤية ماذا.
اختر نمط تكامل، وستبدأ الأنظمة في الاعتماد على توقيته وسلوكه.
كلما طال وجود تلك القرارات، زادت جاذبيتها. وفي النهاية، يعني تغيير القرار الأصلي تغيير كل ما تراكم حوله.
والذكاء الاصطناعي يشعر بتلك الجاذبية أيضًا. فأداة الذكاء الاصطناعي تعمل انطلاقًا مما هو موجود بالفعل في النظام: بمجرد أن يوجد عنصر تصميم أساسي، يتعامل كل تفاعل لاحق مع الذكاء الاصطناعي مع ذلك العنصر على أنه حقيقة، ويواصل البناء عليه، والبناء عليه، والبناء عليه. يتردد صدى القرار إلى الأمام عبر قرارات أخرى كثيرة، ولا يعود أي إنسان أبدًا لمراجعة القرار الأصلي. وكل جيل جديد يزيد الجاذبية.
لهذا يهم أن يكون نموذج البيانات «الهيكل العظمي». لسنا حذرين لأن التغيير سيئ. نحن حذرون لأن الاعتماديات تجعل التغيير مكلفًا.
اطرح سؤالين
Section titled “اطرح سؤالين ”عندما أنظر إلى قرار تصميم، أطرح سؤالين:
ما مدى صعوبة التراجع عن هذا؟
كم من الأشياء سيعتمد عليه؟
السؤالان مترابطان، لكنهما ليسا متطابقين. قد يكون الشيء سهل التغيير تقنيًا لكن له مئات المستهلكين. كان الناس يعيدون تسمية الكائنات القياسية من أجل الوضوح، كأن يُسمّى الحساب (Account) «Customer» مثلًا. أمر سهل. ثم أراد نظام آخر استخدام الحسابات للشركاء (Partners)، ولم يستطع. وشيء آخر قد لا يكون له إلا عدد قليل من المستهلكين لكنه يحتاج إلى ترحيل هائل لتغييره، مثل اسم API لكائن يُشار إليه في أماكن كثيرة داخليًا. لا أحد من الخارج يراه، لكن الاسم الخاطئ يظل يربك الفريق. وكلاهما يستحق الاهتمام.
فكّر في بعض قرارات البيانات الشائعة:
- أي كائن في Salesforce يمثّل مفهوم العمل هذا؟
- ما المعرّف الفريد؟
- أي نظام هو نظام السجل (system of record)؟
- هل تُنسخ هذه البيانات إلى Salesforce أم يُوصَل إليها في مكان آخر؟
- هل هذا كائن واحد أم عدة كائنات مترابطة؟
- من يملك البيانات، وإلى متى نحتفظ بها؟
- ما حدود الوصول الافتراضية لدينا؟
- كيف تنتقل هذه البيانات بين الأنظمة؟
هذه مختلفة تمامًا عن تحديد مكان ظهور حقل في صفحة Lightning. تصميم الصفحة مهم أيضًا. لكن كلفة الخطأ مختلفة.
فكّر في نطاق الضرر
Section titled “فكّر في نطاق الضرر ”طريقة أخرى للتفكير في قابلية التراجع هي نطاق الضرر (blast radius): إذا غيّرت هذا القرار، فما الذي يتحرك معه أيضًا؟
لنفترض أن شيئًا نمذجناه حقلًا يحتاج في الحقيقة إلى أن يصبح كائنًا فرعيًا. هذا ليس مجرد تغيير في المخطط (schema). ماذا يحدث للبيانات الموجودة؟ وللتقارير، ولعمليات التكامل التي تتوقع ذلك الحقل، ولشيفرة Apex وعمليات Flow التي تشير إليه، وللأمان، وللتحليلات، ولوكيل ذكاء اصطناعي تعتمد إجراءاته على البنية الأصلية؟
كلما اتسع النطاق، وجب أن نتخذ القرار الأصلي بعناية أكبر.
ولهذا أيضًا على المعماريين أن ينظروا إلى ما وراء جزئهم من النظام. من داخل Salesforce، قد يبدو التغيير سهلًا. ومن منظور المؤسسة، قد يؤثر في اثني عشر نظامًا آخر.
قرارات المؤسسة وقرارات Salesforce
Section titled “قرارات المؤسسة وقرارات Salesforce ”يفكر معماري البيانات على مستويين.
داخل Salesforce، نقرر الكائنات، والعلاقات، والمفاتيح، والحجم، والوصول، والأتمتة، وكيف تتصرف البيانات على المنصة.
على مستوى المؤسسة، نطرح أسئلة أوسع. أين يعيش «العميل» فعلًا؟ من يملك «المنتج»؟ أي نظام يُنشئ «الطلب»؟ ما معرّفنا المرجعي المعتمد؟ أي المعلومات تُنسخ بين الأنظمة، وأيها يبقى في مكانه؟
يجب أن يتصل المستويان. رأيت عمليات تنفيذ لـSalesforce كان نموذجها الداخلي منطقيًا تمامًا بحد ذاته، لكنه لم يتلاءم مع المؤسسة من حوله. هذا لا يكفي. يجب أن تُمثَّل بنى Salesforce على مستوى المؤسسة، ويجب أن تتدفق قرارات المؤسسة عائدة إلى Salesforce.
المعمارية طريق ذو اتجاهين.
تمهّل في القرارات المكلفة
Section titled “تمهّل في القرارات المكلفة ”أحد المخاطر في التقنية أن القرارات الأسهل تنفيذًا قد تبدو هي الأسهل اتخاذًا. وهما ليسا الشيء نفسه.
إنشاء كائن مخصص آخر أمر سهل. إنشاء حقل آخر أمر سهل. ربط واجهة API أخرى يزداد سهولة، والذكاء الاصطناعي يجعل كل ذلك أسهل.
لكن سهولة التنفيذ لا تخبرنا شيئًا يُذكر عن كلفة القرار المعماري.
قبل أي قرار يصعب التراجع عنه، تمهّل بما يكفي لتسأل: ما المشكلة التي نحلها فعلًا؟ ما البدائل التي درسناها؟ ما الذي نفترضه؟ ماذا يحدث مع نمو الحجم، ومع تغيّر العمل؟ ما الذي سيعتمد على هذا أيضًا؟ ماذا يحدث إذا كنا مخطئين؟
لا نحتاج إلى ستة أشهر من المراجعة في كل مرة ننشئ فيها كائنًا. لكننا نحتاج إلى تفكير يتناسب مع كلفة الخطأ. إذا كان الكائن لقسم واحد أو نظام فرعي، يمكنك أن تتحرك بسرعة أكبر. وإذا كانت بيانات مرجعية، أو كائن عملاء أساسيًا، أو شيئًا يُستخدم عبر الأنظمة، فخذ وقتك في التفكير فيه جيدًا.
اكتب السبب
Section titled “اكتب السبب ”هناك مشكلة أخرى في القرارات المهمة: ينسى الناس لماذا اتُّخذت.
ينظر أحدهم إلى معمارية بعد ثلاث سنوات ويسأل: «لماذا قد يصمم أي شخص الأمر بهذه الطريقة؟» أحيانًا تكون الإجابة أنه كان تصميمًا سيئًا. هذا يحدث. لكن أحيانًا كان هناك سبب وجيه جدًا: قيد في المنصة لم يعد موجودًا، أو متطلب تنظيمي، أو نظام آخر لم يستطع دعم النهج المفضّل، أو مفاضلة قُبلت عن وعي للالتزام بموعد نهائي.
إذا سجّلنا فقط ماذا قررنا وليس لماذا، فلن تكون لدى المعماري التالي أي وسيلة لمعرفة ذلك.
بالنسبة للقرارات المهمة، اكتبها. لا يلزم أن تكون وثيقة من 50 صفحة. يمكن أن يكون سجل القرار المفيد صغيرًا جدًا:
السياق: ما المشكلة التي نحلها؟
الخيارات: ما البدائل الواقعية التي درسناها؟
القرار: ماذا اخترنا؟
العواقب: ماذا نكسب، وما الذي نتخلى عنه؟
المالك: من المسؤول عن هذا القرار؟
المراجعة: ما السبب أو التاريخ الذي ينبغي أن يدفعنا إلى إعادة النظر فيه؟
القيمة ليست في الوثيقة. القيمة في الحفاظ على المنطق الذي قاد إلى القرار.
وعندما يتغير قرار، لا تمحُ الأصلي. بل استبدله بقرار جديد يحلّ محله. فالقرار الذي كان صحيحًا في 2027 قد لا يكون صحيحًا في 2030، لأن الأحجام، والعمل، وSalesforce، وفهمنا، كلها تتغير. ما أريد الاحتفاظ به هو القصة: هذا كان السياق، وهذا كان القرار وسببه، وهذا ما تغيّر، وهذا ما نقرره الآن. وهذا أثمن بكثير من التظاهر بأننا كنا نعرف الإجابة دائمًا.
ما بعد الاختبار: الذكاء الاصطناعي يختصر الوقت من القرار إلى الاعتمادية. تستطيع أداة الذكاء الاصطناعي أن تقترح نموذج بيانات في ثوانٍ، ثم تُنشئ فوقه الكائنات، والأتمتة، وشيفرة التكامل، وواجهة المستخدم. كان القرار المشكوك فيه يحتاج إلى أشهر من التطوير قبل أن يعتمد عليه الكثير؛ أما الآن فتصل الاعتماديات فورًا تقريبًا. لذلك راجع القرارات التي تقوم عليها المخرجات، لا المخرجات وحدها. يمكن للذكاء الاصطناعي أن يساعد: يستطيع سرد الخيارات، وتحدي الافتراضات، وصياغة مسودة سجل القرار. لكن المعماري هو من يقرر، وكلما كان التراجع عن القرار أصعب، زادت أهمية ذلك الحكم البشري.
اعرف أي القرارات مهمة
Section titled “اعرف أي القرارات مهمة ”من المهارات التي أريدك أن تكتسبها أن تعرف أين تصرف اهتمامك.
لا تحوّل كل خيار إعداد إلى قمة معمارية.
لكن لا تتخذ باستخفاف قرارًا ستعيش معه المؤسسة طوال العقد القادم.
اسأل:
ما مدى صعوبة التراجع عن هذا؟
كم من الأشياء سيعتمد عليه؟
إذا كانت الإجابتان صعب جدًا والكثير، فالأرجح أنك وجدت قرارًا معماريًا.
تمهّل. افهم المتطلب. استكشف البدائل. اجعل المفاضلات مرئية. اتخذ القرار. واكتب السبب.
ليس هدف المعمارية أن نتخذ قرارات لا يمكن أن تتغير أبدًا.
الهدف هو أن ندرك القرارات التي سيكون فيها تغيير رأيك مكلفًا.
ما الذي يقرره المعماري هنا
Section titled “ما الذي يقرره المعماري هنا ”- أي القرارات معمارية: يصعب التراجع عنها، ويعتمد عليها الكثير.
- كم من الاهتمام يحصل عليه كل قرار، بما يتناسب مع كلفة الخطأ.
- أي القرارات تُكتب، مع سياقها، وخياراتها، وعواقبها، ومالكها، ونقطة مراجعتها.
- كيف تتسق قرارات Salesforce مع قرارات المؤسسة.
للاستزادة
Section titled “للاستزادة ”- Object Relationships Overview (opens in a new tab)، Salesforce Help (بالإنجليزية، تم التحقق في 2026-10-09؛ وأُعيد التحقق في 2026-10-12): في علاقة رئيسي-تفصيلي (master-detail)، يتبع وصولُ السجل التفصيلي وملكيتُه السجلَّ الرئيسي، وحذف السجل الرئيسي يحذف سجلاته التفصيلية.
- Considerations for Object Relationships (opens in a new tab)، Salesforce Help (بالإنجليزية، تم التحقق في 2026-10-09؛ وأُعيد التحقق في 2026-10-12): لا تتحول علاقة البحث (lookup) إلى رئيسي-تفصيلي إلا عندما يكون لكل سجل قيمة فيها؛ والتحويل يغيّر نموذج المشاركة (إلى Controlled by Parent)، ونوع العلاقة يحدد أنواع التقارير القياسية المتاحة.
- Roll-Up Summary Field (opens in a new tab)، Salesforce Help (بالإنجليزية، تم التحقق في 2026-10-09؛ وأُعيد التحقق في 2026-10-12): الحقول الملخصة التجميعية (roll-up summary) لا توجد إلا في علاقات رئيسي-تفصيلي، ويجب حذفها قبل أن تتحول علاقة رئيسي-تفصيلي إلى علاقة بحث.