2.2 مبادئ تصميم البرمجيات

نظرة عامة والدافع

مبادئ تصميم البرمجيات هي إرشادات لترتيب الشيفرة بحيث تستطيع فهمها وتغييرها وتوسيعها بمرور الوقت. تشمل اختصارات مسماة (SOLID لخمسة مبادئ تصميم كائنية التوجه، وDRY لـ”لا تكرر نفسك”، وKISS لـ”أبقِ الأمر بسيطًا”، وYAGNI لـ”لن تحتاجه”)، ومفاهيم بنيوية (الاقتران، والتماسك، وفصل الاهتمامات)، وأنماط تصميم موثّقة، ومناهج نمذجة أعلى مستوى مثل التصميم الموجه بالمجال (نمذجة البرمجيات بلغة مجال العمل)، والاختيار بين الأساليب كائنية التوجه والوظيفية والموجهة بالبيانات. لا شيء من هذا قوانين. إنها خبرة مضغوطة، ويجب أن تطبقها بحكمة.

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

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

المبادئ الأساسية

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

التوصيات

استخدم SOLID كعدسة لا كقائمة مرجعية

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

طبّق DRY على المعرفة لا على النص

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

دع KISS وYAGNI يقاومان التخمين

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

صمم من أجل اقتران منخفض وتماسك عالٍ صراحة

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

استخدم أنماط التصميم كمفردات، وطبّق الأنماط المضادة كتحذيرات

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

تبنَّ التصميم الموجه بالمجال حيث يكون المجال معقدًا

للأنظمة ذات القواعد التجارية الغنية، استخدم أدوات DDD التكتيكية والاستراتيجية: لغة موحدة مشتركة مع خبراء المجال، وسياقات محدودة تقسّم النظام إلى قطع منمذجة باستقلالية، وخرائط سياق تصف كيفية ارتباط تلك القطع. تكون السياقات المحدودة قيّمة بوجه خاص على نطاق المؤسسة، لأنها توائم ملكية الفريق مع حدود النموذج. DDD مبالغ فيه لأنظمة CRUD (إنشاء، قراءة، تحديث، حذف) البسيطة.

اختر المنهجيات وفق الملاءمة

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

المفاضلات: الإيجابيات والسلبيات

المبدأ / النهج	مطبَّق جيدًا	نمط الفشل
SOLID	مفاصل واضحة حيث يحدث التغيير؛ وحدات قابلة للاختبار	تكاثر الواجهات والطبقات؛ إحالة بلا عائد
DRY	مصدر حقيقة واحد لمعرفة حقيقية	تجريد خاطئ يقرن شيفرة غير مرتبطة
KISS / YAGNI	أنظمة نحيلة ومفهومة	مفاصل ناقصة التصميم؛ تعديلات لاحقة مكلفة لمرونة كانت مطلوبة
أنماط التصميم	مفردات مشتركة؛ بنى مُثبتة	تقليد الأنماط بلا فهم؛ تعقيد عرضي
التصميم الموجه بالمجال	نماذج وفرق متوائمة؛ تعقيد مروَّض	مراسم ثقيلة على مجالات بسيطة؛ حدود سياق في غير موضعها
الوظيفي / الثابت	قابلية تنبؤ؛ تزامن أكثر أمانًا	ملاءمة محرجة للمشكلات ذات الحالة أصلًا؛ مفاجآت في الأداء

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

أسئلة للنقاش مع فريقك

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

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

3. أين يقع الخط في أنظمتك بين مجال غني بما يكفي لتبرير التصميم الموجه بالمجال وتطبيق CRUD بسيط حيث يكون مبالغًا فيه؟ يوصي الفصل بالسياقات المحدودة لـDDD تحديدًا لأنها توائم ملكية الفريق مع حدود النموذج، ويحذر من أن DDD مبالغ فيه لأنظمة إنشاء-قراءة-تحديث-حذف البسيطة ويتدهور إلى مراسم بلا نمذجة حقيقية. الخطأ في أي اتجاه مكلف: DDD ثقيل على مجال رقيق يدفن تطبيقًا بسيطًا في المراسم، بينما نموذج مشترك متمدد عبر فرق كثيرة يفرض تنسيقًا مستمرًا بين الفرق. أحضر الإشارات التي تحسم الأمر فعليًا: كثافة القواعد التجارية، وعدد الفرق التي تحتاج امتلاك قطع باستقلالية. احجز الآلية الاستراتيجية للنواة المعقدة، ودع الأطراف البسيطة تبقى بسيطة. هذا يبقيك بعيدًا عن مسرحية DDD وكرة الطين الكبيرة معًا.

4. متى يستحق تجريد أو واجهة أو نمط تصميم الإحالة التي يضيفها، ومن له سلطة وصف تصميم بالإفراط في الهندسة؟ هذا الفصل صريح في أن للإحالة تكلفة تدفعها في كل قراءة، وأن صناعة واجهات ومصانع وطبقات لإرضاء SOLID أو لتبدو متطورًا نمط فشل. في فريق كبير، يسير الضغط في الاتجاه المعاكس: يمرر المراجعون تجريدًا إضافيًا لأنه يبدو منضبطًا، ولا يريد أحد أن يكون الشخص الذي يجادل من أجل بنية أقل. الاعتبار المنافس حقيقي، لأن بعض المفاصل تستحق فعلًا وجودها وإزالتها لاحقًا مكلفة. أحضر أدلة ملموسة إلى النقاش: كم تطبيقًا لواجهة موجود فعليًا اليوم، وكم مرة انثنت نقطة التوسيع فعليًا، وكم ملفًا يجب على القارئ فتحه لتتبع مسار شيفرة واحد. اتفق على أن تطبيقًا واحدًا بلا ثانٍ في الأفق سبب افتراضي للدمج المباشر، وسمِّ من يستطيع وصف تصميم بالإفراط في الهندسة دون أن يُقرأ ذلك كإهانة. في أنظمة المؤسسات والحكومة التي تعيش أطول من مؤلفيها بعقد، الإحالة غير المبررة ضريبة يدفعها كل قائم على الصيانة مستقبلًا، لذا عامل سؤال “ماذا يشترينا هذا التجريد” كسؤال مراجعة دائم لا تحديًا شخصيًا.

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

6. كيف تمنع هذه المبادئ من التصلب إلى عقيدة، وأين تسجل التفكير وراء قرار تصميم بحيث يستطيع فريق مستقبلي مراجعته؟ لكل مبدأ في هذا الفصل نطاق تطبيق ونمط فشل، ويعامل التأطير كله المبادئ كأدوات تُطبَّق بحكمة لا قوانين تُفرض. في فريق كبير يتحول المبدأ بهدوء إلى قاعدة: يمنع DRY أي تكرار، ويفرض SOLID واجهة لكل صنف، وتُحجب الاستثناءات العملية في المراجعة من قِبل من يستشهدون بالاختصار لا بالنتيجة. التوتر هو أن بعض الاتساق يساعد فعلًا مئات المهندسين على التنسيق، لذا لا يمكنك ببساطة إعلان أن كل مبدأ اختياري. أحضر أمثلة حيث أنتج اتباع مبدأ بحرفيته تصميمًا أسوأ، وأحضر سجلات القرار، إن وُجدت، التي تشرح لماذا يوجد حد أو تجريد معين. اتفق على أن المبادئ افتراضات يمكن للمهندس الانحراف عنها بسبب مسجل، ودوّن اختيارات التصميم المهمة في سجل قرار معماري قصير بحيث يرث الفريق التالي التفكير لا الشيفرة فقط. في أنظمة المؤسسات والقطاع العام، حيث رحل المؤلفون الأصليون منذ زمن طويل وتسأل عمليات التدقيق لماذا شُكِّل النظام على هذا النحو، يصنع ذلك الأثر المكتوب الفارق بين تصميم تستطيع الفرق المستقبلية تغييره بأمان وآخر تخشى لمسه.

المنظور القطاعي

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

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

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

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

أمثلة

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

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

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

حالة العمل: الدوافع والعائد على الاستثمار وتكلفة الملكية الإجمالية

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

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

الأنماط المضادة والمزالق

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

نموذج النضج

• المستوى 1، الشروع: التصميم عشوائي وتفاعلي؛ يتراكم الاقتران دون رقابة؛ المبادئ مجهولة أو تُستحضر كشعارات، وتظهر التجريدات أو تختفي حسب العادة الفردية.
• المستوى 2، التطوير: تعرف الفرق المبادئ وتطبقها، لكن بتفاوت وغالبًا بعقائدية؛ تدير بعض المجموعات الاقتران والتماسك عمدًا بينما لا تفعل أخرى، ولا توجد مفردات مشتركة عبر المؤسسة.
• المستوى 3، التوحيد القياسي: تُوثَّق مفردات تصميم مشتركة، وقاعدة الثلاثة لاستخراج التجريدات، وتحليل الاقتران والتماسك، وسياقات محدودة موائمة للفرق، وتُتوقع على نطاق المؤسسة، وتُطبَّق باتساق في مراجعة التصميم بدل تركها للذوق الفردي.
• المستوى 4، الإدارة: تُقاس صحة التصميم مقابل خطوط أساس: تُتبَّع بيانات الاقتران والتغيير المشترك، ومعدل فشل التغيير، والوقت اللازم لتنفيذ ميزات مماثلة بمرور الوقت، بحيث تُضاف التجريدات والحدود أو تُبقى أو تُزال بناءً على الأدلة، ويُكتَشف الإفراط في الهندسة والتجريد الخاطئ بالبيانات لا الرأي.
• المستوى 5، التنسيق الشامل: يُدمَج انضباط التصميم مع التسليم وتخطيط المخاطر عبر المؤسسة؛ تُطبَّق المبادئ بدقة وأنماط فشل معروفة؛ اختيارات المنهجية والحدود متعمدة ومُراجَعة باستمرار، وتعيد المؤسسة بانتظام هيكلة التجريدات وإعادة تحديد نطاقها وإلغاءها مع تحول المجال والأدلة.

أفكار للنقاش

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

النقاط الرئيسية

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

المراجع والقراءات الإضافية

• Robert C. Martin, Clean Architecture and Agile Software Development, Principles, Patterns, and Practices
• Eric Evans, Domain-Driven Design: Tackling Complexity in the Heart of Software
• Vaughn Vernon, Implementing Domain-Driven Design
• Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides, Design Patterns: Elements of Reusable Object-Oriented Software
• Martin Fowler, Refactoring: Improving the Design of Existing Code and Patterns of Enterprise Application Architecture
• David L. Parnas, On the Criteria to Be Used in Decomposing Systems into Modules
• Sandi Metz, Practical Object-Oriented Design