تصميم يحركه المجال: وصفة لالبراغماتية

لماذا عادة ما يتم تناول DDDs من الجانب الخطأ؟ وأي جانب تريد؟ ما علاقة الزرافات والخلدمات مع كل هذا؟

خاصة بالنسبة لـ Habr - نسخة نصية من التقرير "التصميم القائم على المجال: وصفة للبراغماتي". تم إعداد التقرير في مؤتمر DotNext .NET ، ولكن يمكن أن يكون مفيدًا ليس فقط للمانحين ، ولكن أيضًا لكل من يهتم بـ DDD (نعتقد أنكم سوف تتقنون بضعة أمثلة من رموز C #). كما يتم إرفاق تسجيل فيديو للتقرير.



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



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

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

لكن الزرافة على ما يرام ، لأن هناك خلد الماء.


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

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

أعلم ما تفكر فيه الآن: "أليكسي ، لقد وعدتم بتصميم يحركه النطاق ، وهنا نوع من" عالم الحيوان "!"

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

الأول هو تعقيد العمليات التجارية نفسها ، أي صعوبة فهم كيفية عمل الأعمال التجارية ، وما هي العمليات التي تجري هناك ، وأي منطق يتم بناؤه.

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

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

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

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

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

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



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

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

على اليمين هو ما يحدث إذا رميت بجنون أنماط تكتيكية على المترجم. اليسار - إذا كنت تستخدم أنماط استراتيجية.



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

وبعد 10 سنوات ، في عام 2013 ، تم نشر الكتاب الأحمر من قبل Vaughn Vernon. وفي هذا الكتاب ، تم بناء العرض التقديمي بالفعل بالترتيب الصحيح: يبدأ بالتصميم الاستراتيجي ، مع الأساسيات. وعندما يتلقى القارئ القاعدة اللازمة ، يبدأون بالفعل في الحديث عن الأنماط التكتيكية وتفاصيل التنفيذ.

عادةً في التقارير المتعلقة بـ DDD ، يوصون بقراءة Evans ، على الإنترنت ، هناك أدلة كاملة تحتاج إلى قراءة فصول لغمرها بشكل صحيح. أوصي بالقيام بذلك بشكل أسهل: ابدأ بالكتاب الأحمر ، ثم اقرأه ، ثم انتقل إلى اللون الأزرق.

وبما أن التصميم الاستراتيجي أمر مهم ، فلنتحدث عن أفكاره الرئيسية.

"الأفكار الرئيسية للتصميم الاستراتيجي"

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



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

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

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



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

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



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

سيناريوهات العمل

لمزيد من المناقشة ، نحتاج إلى نوع من سيناريو العمل. دعونا نتخيل هذا الموقف:



يأتي مدير مجموعة JUG.ru إلينا ويقول: "أيها الرجال ، تدفق التقارير آخذ في الازدياد ، والناس ، بشكل عام ، يتعرضون للتعذيب لفعل كل شيء يدويًا ... دعنا نتمكّن من عملية الإعداد للمؤتمر." نرد: "حسنًا!" - وذهب إلى العمل.

السيناريو الأول الذي سنعمل عليه تلقائيًا هو: "يقدم المتحدث طلبًا لتقرير في حدث معين ويضيف معلومات حول تقريره." ماذا نرى في هذا السيناريو؟ ما هو المتكلم ، هناك حدث ، وهناك تقرير ، مما يعني أنه من الممكن بالفعل بناء نموذج المجال الأول.



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



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

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



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

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

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

عرض توضيحي: خدمة المبيعات

دعنا نستخلص القليل من النظرية الجافة وننظر إلى الكود.

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

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

يمكن عرض الشفرة التي سنحللها الآن بشكل منفصل في المستودع .

افتح الحل ، انظر إلى الهيكل:



يبدو أن كل شيء يبدو جيدًا: هناك تطبيق و Core (على ما يبدو ، يعرف الناس عن الطبقات) ، ومستودع ... على ما يبدو ، فإن الشخص يتقن النصف الأول من Evans.

افتح OrderCheckoutService. ماذا نرى هناك؟ هنا هو الكود :

public void Checkout(long id) { var ord = _ordersRepository.GetOrder(id); var orders = _ordersRepository.GetOrders() .Count(o => o.CustomerId == ord.CustomerId && o.StateId == 3 && o.OrderDate >= DateTime.UtcNow.AddYears(-3)); ord.Price *= (100 - (orders >= 5 ? 30m : orders >= 3 ? 20m : orders >= 1 ? 10m : 0)) / 100; ord.StateId = 1; _ordersRepository.SaveOrder(ord); } 

نحن ننظر إلى السطر مع السعر: هنا يتغير السعر. ندعو مدير المبيعات لدينا ونقول: "هنا ، باختصار ، يعتبر الخصم هنا ، كل شيء واضح":

 ord.Price *= (100 - (orders >= 5 ? 30m : orders >= 3 ? 20m : orders >= 1 ? 10m : 0)) / 100; 

إنه ينظر على كتفه: "أوه! هذا ما يشبه Brainfuck! وأخبروني نوعًا ما أن الرجال يكتبون في C # ".

من الواضح أن مطور هذه الشفرة قد استجاب جيدًا لمقابلة حول الخوارزميات وهياكل البيانات. كتبت في أولمبياد المدرسة في نفس النمط تقريبا. بعد مرور بعض الوقت ، باستخدام التنسيق وإعادة البناء الفاحش ، نكتشف ما الذي نوضحه ، ونشرح لمدير المبيعات الذي طالت معاناته أن المنطق هو هذا: إذا كان عدد الطلبات في آخر 3 سنوات أقل من واحد ، فسيحصل على خصم بنسبة 10 ٪ ، لا تقل عن ثلاثة - 20 ٪ ، وليس أقل من خمسة - 30 ٪. يترك البهجة - والآن أصبح من الواضح كيف يعمل كل شيء.

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

هنا هو رمز refactored.

  public class DiscountCalculator { private readonly IOrdersRepository _ordersRepository; public DiscountCalculator(IOrdersRepository ordersRepository) { _ordersRepository = ordersRepository; } public decimal CalculateDiscountBy(long customerId) { var completedOrdersCount = _ordersRepository.GetLast3YearsCompletedOrdersCountFor(customerId); return DiscountBy(completedOrdersCount); } private decimal DiscountBy(int completedOrdersCount) { if (completedOrdersCount >= 5) return 30; if (completedOrdersCount >= 3) return 20; if (completedOrdersCount >= 1) return 10; return 0; } } 

أول شيء نقوم به هو نقل حساب الخصم إلى DiscountCalculator منفصل ، والذي يظهر فيه الأسلوب CalculateDiscountBy customerId. كل شيء يقرأ إنسانيا ، كل شيء واضح: ماذا ولماذا وكيف. داخل هذه الطريقة ، نرى أن لدينا خطوتين عالميتين لحساب الخصم. أولاً: نحصل على شيء من مستودع الطلبات ، كل شيء وفقًا لحالة المستخدم ، لست مضطرًا حتى للدخول إلى الداخل إذا لم يكن هذا هو الجزء الذي يثير اهتمامك الآن. الحقيقة هي أننا نحصل على عدد من الطلبات المكتملة ، وبعد ذلك نعتبر على الفور أن الخصم الثاني لهذه الكمية هو الخطوة الثانية.

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

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

 public void CheckoutV2(long orderId) { var order = _ordersRepository.GetOrder(orderId); var discount = _discountCalculator.CalculateDiscountBy(order.CustomerId); order.ApplyDiscount(discount); order.State = OrderState.AwaitingPayment; _ordersRepository.SaveOrder(order); } 

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

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



هذه هي النقطة الرئيسية الثالثة.

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



يعد المجال شيئًا عالميًا ، وهو مجال موضوع عالمي تجني فيه هذه الأعمال التجارية الخاصة الأموال. على سبيل المثال ، بالنسبة إلى DotNext ، يعد هذا مؤتمرًا ، أما بالنسبة إلى Pyaterochka فهو عبارة عن بيع بالتجزئة للسلع.

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

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



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

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



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

تنقسم المجالات الفرعية إلى ثلاثة أنواع.



الأول والأهم هو كور. Core هي المجال الفرعي الرئيسي ، وهذه هي الميزة التنافسية للشركة ، ما الذي يجعل هذه الشركة أموالًا ، وكيف تختلف عن منافسيها ، ومعرفتها ، ومهما سمّتها. إذا أخذنا مؤتمر DotNext ، فهذا هو المحتوى. أتيت جميعًا إلى هنا للمحتوى ، إذا لم يكن هناك مثل هذا المحتوى هنا ، فلن تذهب أو تذهب إلى مؤتمر آخر. لن يكون هناك DotNext بالشكل الذي به.



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

مثال على نفس DotNext هو التسويق. هذا مستحيل بدون التسويق ، وإلا فلن يعرف أحد عن المؤتمر ، ولكن بدون الحاجة إلى تسويق المحتوى.



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

على سبيل المثال ، بيع التذاكر. تبيع DotNext التذاكر عبر TimePad. هذا النطاق الفرعي مؤتمت تمامًا بواسطة TimePad ، ولن تحتاج إلى كتابة TimePad ثانية بنفسك.



وأخيرا ، يحدها السياق. يقع السياق المحيط به والنطاق الفرعي دائمًا في مكان ما قريبًا ، ولكن يوجد فرق كبير بينهما. هذا مهم جدا



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



مثال كلاسيكي: إمساك الدفاتر كمجال فرعي ، وكيفية تعيين العملية ، بطريقة تلقائية ، على سبيل المثال ، 1C مسك الدفاتر ، إلبا أو "عملي" - يتم آليًا بطريقة ما بواسطة بعض المنتجات. هذا هو السياق المحدود للمحاسبة ، حيث توجد لغته في كل مكان ، ومصطلحاته الخاصة. هذا هو الفرق بينهما.



إذا عدنا إلى DotNext ، فحينئذٍ ، كما قلت ، يتم تعيين التذاكر إلى TimePad ، ويتم تعيين المحتوى الذي يمثل Subdomain الخاص بنا إلى تطبيق مخصص نقوم بتطويره لإدارة المحتوى.

حجم السياق يحد

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

دعونا نناقش كيف نفهم نفس الشيء: ما إذا كان يجب أن يكون حلاً أو مشروعًا أو مساحة اسمًا - ما النطاق الذي يجب إرفاقه بالسياق المحيط به؟



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

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

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

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

لكن هذا ليس كل شيء. اسمحوا لي أن أذكرك مرة أخرى بأن التصميم الذي يحركه النطاق يتعلق بالكثير: عن اللغة ، وعن الناس. ولا يمكنك تجاهل الأشخاص والقيام بالمعايير الفنية فقط في هذا الشأن. لذلك ، كتبت هذا: سياق واحد يساوي X-man . كنت أعتقد أن x تبلغ حوالي 10 ، لكننا تحدثنا قليلاً مع Igor Labutin ( twitter.com/ilabutin ) وظل السؤال مفتوحًا.

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

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

العمارة وإدارة التبعية

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



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



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



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



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

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

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

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



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

قليلا عن الأنماط التكتيكية: واجهة منفصلة

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

دعنا نعود إلى رمز الخدمة المصغرة الخاصة بنا ونرى ما حدث مع المستودع.



طبقة المجال لديها واجهة مستودع IOrdersRepository.cs وتطبيقها ، OrdersRepository.cs.

 using System.Linq; namespace DotNext.Sales.Core { public interface IOrdersRepository { Order GetOrder(long id); void SaveOrder(Order order); IQueryable<Order> GetOrders(); #region V2 int GetLast3YearsCompletedOrdersCountFor(long customerId); #endregion } } 

هنا قمنا بإضافة طريقة معينة لتلقي الطلبات على مدار السنوات الثلاث الأخيرة GetLast3YearsCompletedOrdersCountFor.

وقاموا بتنفيذه بشكل ما (في هذه الحالة ، من خلال إطار الكيان ، ولكن يمكن أن يكون أي شيء):

  public int GetLast3YearsCompletedOrdersCountFor(long customerId) { var threeYearsAgo = DateTime.UtcNow.AddYears(-3); return _dbContext.Orders .Count(o => o.CustomerId == customerId && o.State == OrderState.Completed && o.OrderDate >= threeYearsAgo); } 

ترى ما هي المشكلة. انتهى المخزون في طبقة المجال ، وتطبيقه في طبقة المجال ، لكن الكود ، بدءًا من DateTime.UtcNow.AddYears (-3) ، لا ينتمي بطبيعته إلى طبقة المجال ، وليس منطقًا تجاريًا. نعم ، يجعل LINQ الأمر أكثر انسانية أو أقل ، ولكن ، على سبيل المثال ، إذا كانت هناك استعلامات SQL هنا ، فسيكون كل شيء محزنًا تمامًا.

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

أعددت خيارًا آخر. تظل واجهة المستودع في التجميع Core ، لكن التنفيذ ينتقل إلى Infrastructure.EF.



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

مرة أخرى عن اللغة

دعونا نتحدث مرة أخرى ، ومرة ​​أخرى ، ومرة ​​أخرى عن اللغة.

في البداية ، قمنا ببناء نموذج مجال "المتكلم - الحديث - الحدث". أعتقد أن أحدا لم يطرح أي أسئلة خاصة.

وإليك السيناريو الذي قمنا على أساسه ببناء نموذج المجال هذا:



انظر ، البرنامج النصي باللغة الروسية ، ونموذج المجال باللغة الإنجليزية.

للمطورين الذين لا يتحدثون الإنجليزية ، هذا شيء يتعين عليك التعايش معه باستمرار.



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

, , , . , .

1, . , — , , .



1. PascalCase , , , , , , , - - .

, - ?



, use case, , . , . C#, , , . , , , .

, , Domain-Driven Design. , , , , C# . .

, - Continuous Integration. , , , - - . , - , , . , 95% , , Continuous Integration, , TeamCity . .

, . رقم , 1-, , . «» , . , , .



, Domain-Driven Design.

— , . Domain-Driven Design — , . — , , ubiquitous language. , , . , , , .

. , . - , , , , , , , , , , — . .

. . . . , , . DSL-. .NET-, - , , , , . , .

, - . , , ubiquitous language -. .

• marshinov . , DDD: , « DDD, CQRS Event Sourcing » . , , .
• , AutoMapper MediatR. , Domain-Driven Design, .
• «F# for fun and profit» , , F# Domain-Driven Design. , , , .
• , , .

, , GitHub .

DotNext:
, « , ». DotNext ( 15-16 ) . , 1 , .