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

في مقال سابق في هذه السلسلة ، قمت بنشر خريطة مفاهيم تظهر العلاقات بين أنواع الأكواد.

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

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

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



على الرغم من موقعه ، لم أقصد أن النواة المشتركة تعتمد على بقية الكود أو أن النواة المشتركة هي طبقة أخرى داخل مستوى المجال.

ما هو النواة المشتركة ؟!

النواة المشتركة ، كما حددها إيريك إيفانز ، والد DDD ، هو رمز يقرر فريق التطوير تقسيمه بين عدة سياقات محدودة:

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

- "Common Kernel" ، DDD Wiki من Ward Cunningham

وبالتالي ، يمكن أن يكون أي نوع من التعليمات البرمجية: رمز على مستوى المجال ، رمز على مستوى التطبيق ، مكتبات ... أيا كان.



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

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

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

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

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

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

عندما تكون اللغة غير كافية ...

لذلك ، لدينا رمز التطبيق مع جميع طبقات المركز ، ويعتمد جوهر التطبيق على النواة المشتركة ، والتي تقع تحت كل هذا الرمز.

يمكننا أن نقول أيضًا أن كل هذا الرمز يعتمد على لغة (لغات) البرمجة المستخدمة ، ولكن هذه حقيقة واضحة أننا نميل إلى تجاهلها تمامًا.

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

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

أريد التخلي عن حزم Utils و Commons!

يجب أن يكون لجميع الحزم التماسك المفاهيمي! يجب أن يكون من الواضح متى وكيف تستخدم الحزمة! لا غموض!

على سبيل المثال ، إذا تفاعل أحد التطبيقات مع واجهة سطر الأوامر بطريقة خاصة ، فبدلاً من وضع "Acme / Util / SpecialCli" في مساحة الاسم ، يمكنك وضعه في "Acme / App / Infrastructure / Cli / SpecialCli". هذا يشير إلى أن هذه الحزمة مرتبطة بـ CLI ، فهي جزء من البنية التحتية لتطبيقات Acme. يقول الانتساب إلى البنية التحتية للتطبيق أيضًا أن هناك منفذًا في نواة التطبيق يتوافق مع هذه الحزمة.

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

مثال آخر على ما يمكن اعتباره جزءًا من اللغة هو UUIDs الفريدة في PHP. من الممكن أن نتخيلهم خارج اللغة ، لأنه في كل مرة يكون هناك إصدار جديد وهو كابوس مع دعم الكود ، ولكن هذا مفهوم عام للغاية ، وهو مفهوم واسع ومتسق بما فيه الكفاية ليكون جزءًا من اللغة.

فلماذا لا تقوم بإنشاء تطبيق UUID واستخدامه مثل جزء من PHP نفسه ، كيف نستخدم كائن DateTime؟! بينما نتحكم في التنفيذ ، لا أرى أي عيوب.

ماذا عن لغة الاستعلام العقيدة (DQL)؟ (العقيدة هي منفذ السبات في PHP) هل يمكن أن ننظر إلى DQL كما لو كانت SQL أو Elasticsearch QL أو Mongo QL؟

الخلاصة

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



بالنسبة لي ، الحقيقة التي لا يمكن إنكارها هي أن العمارة موجودة دائمًا ، والسؤال الوحيد هو ما إذا كنا نسيطر عليها أم لا ؟!

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