مقدمة

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

المشكلة التي يحلّها DDD

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

اللغة الموحّدة

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

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

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

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

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

الكيانات وكائنات القيمة والتجميعات

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

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

التصميم الاستراتيجي وهيكلة الفرق

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

متى لا يكون DDD الأداة المناسبة

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

مثال عملي: نمذجة مطالبة تأمينية

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

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

DDD والعلاقة بالخدمات المصغّرة

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

الخاتمة

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