صورة من مدونة tomaszjaniak
تبين لنا العمارة الخاصة بك
يحدث ذلك لأنك كنت تعمل في مشروع لمدة عامين ، والآن أنت جالس على أكواعك في الكود ، والاختبارات تحترق ، ومبرد الكمبيوتر المحمول يُحدث ضوضاء ، ويحاول تبريد حرارة المعالج المحموم من قبل المترجم ، بضع ساعات أخرى - وستنتهي إعادة البناء. ومن ثم نحتاج بشكل عاجل إلى إسقاط كل شيء ورسم بنية المشروع. يتم التخطيط لعميل كبير ، ومن أجل إغلاق الصفقة ، من الضروري الخضوع للتدقيق. وفي هذه الحالة ، لا يوجد مكان بدون المخططات المعمارية. إذن ماذا لو كان المشروع لا يزال صغيراً ، ولم يكن العشرات من مطوريه في العمل الحقيقي بحاجة إلى أي هندسة معمارية هناك. ها هو الرمز - كل شيء واضح. لكن لا يوجد مخرج. إنه ضروري - إذن فهو ضروري.
إذا كنت تعرف كيف يعمل كل شيء ، فيمكن رسم بنية أي منتج في غضون ساعة. وهذا عادة ما يكون كافيا للمراجعة. بعد كل شيء ، ليس الهدف من التدقيق هو أن يفهم الغرباء بنية منتجك حقًا. بيت القصيد من السؤال هو تحديد ما إذا كان مطورو المنتج أنفسهم يفهمون ما يفعلونه. وإذا تحدثت بثقة كافية وأجبت على الأسئلة دون تردد ، فسيتم كل شيء بسلاسة. ولكن مع ذلك ، عندما تنتهي هذه القصة ، سوف تستقر الدودة في مكان ما في الأعماق ، الأمر الذي سيزيد من حدة السؤال: ولكن مع ذلك ، ما هو نوع الهندسة المعمارية التي يمتلكها المنتج بالفعل؟ بعد كل شيء ، إذا سألوا ، ربما يكون لدى الآخرين الهندسة المعمارية. وإذا لم يكن لدينا ، فمن الواضح أن هذه فوضى. هناك رغبة كبيرة في القيام بكل شيء بشكل جيد من أجل أن تكون مسؤولاً عن الهندسة المعمارية في المرة القادمة كما ينبغي.
كيف تفعل ذلك بشكل صحيح؟ تحتاج إلى رسم مخططات ووصف الميزات في المستندات ثم تحديث كل هذا. ثم ستكون العمارة. ولكن ، بعد تقديم نطاق العمل ، سرعان ما توصلنا إلى أن كل هذا لا يستحق الوقت المستغرق. ها هو الرمز - كل شيء واضح. وإذا جاء عميل آخر ، فسيكون من الممكن في ساعة أخرى رسم مخطط جديد.
وبعد بضع سنوات ، قد تجد نفسك في موقف معاكس ، ولن تكون المستندات التي ستصف بنية منتج آخر أفضل. بالطبع ، من المفيد معرفة أن الآخرين لديهم بنية سيئة للغاية أيضًا. ولكن عندما يبدأ حجم المشروع في القياس بملايين أسطر التعليمات البرمجية ، وعدد المطورين بالمئات ، فإن مسألة الحاجة إلى الهندسة المعمارية لا تزال مهمة.
هنا ، في إطار سير العمل ، تبدأ العديد من المخططات المعمارية في الظهور ، تبدأ المقترحات المعمارية في الكتابة على الميزات ، تتم مناقشة كل هذا ومراجعته والتحقق من صحته واعتماده ، وبالطبع يصبح قديمًا حتى قبل انتهاء هذه العمليات. ليست هناك حاجة للقول إن مثل هذه المستندات تعكس الهيكل الحقيقي لرمز التطبيق. وعندما يتعلق الأمر بالتنفيذ ، يحدث أن المطورين لا يقرأون هذه المستندات على الإطلاق. أو يتم تنفيذ شيء مختلف تمامًا عما كتب. شخص ما أساء فهم شخص ما ، أو كان من الضروري القيام بذلك بشكل عاجل ، ولم يكن هناك وقت للمناقشة.
ربما كل شيء كما ينبغي أن يكون. ربما ، العمارة هي البيروقراطية حول الوثائق التخمينية ، منفصلة عن الواقع؟ لكن الحدس يخبرنا أنه بعد كل شيء ، لا. إذن ما هي "العمارة" إذن؟
العمارة ...
ماذا يحدث إذا طرحت السؤال "ما هي العمارة؟" عشرة مطورين محترفين؟ إذا لم تتطفل على ويكيبيديا ، فهل سيعطون نفس الإجابة؟
الهندسة المعمارية هي مجموعة من القرارات المهمة ، وهيكل العناصر ، وواجهاتها ، ونظام الأحكام والقواعد والاتفاقيات ، والنهج المشكلة التي تحافظ على النظام ، وحلول المشكلات العالمية ، والتحلل بالتفاعل ، ووصف عالي المستوى للنظام ، ودورة حياته. أجزاء وأنماط الهيكل والسلوك ، وما هو صعب أو مكلف للتغيير أو الإزالة ، والقرارات والمفاضلات الأساسية ، وأكثر من ذلك بكثير.
الهندسة المعمارية هي أيضًا كيف يفي التطبيق بالغرض منه.
API هي بنية معمارية ، مخطط البيانات هو أيضًا معمارية ، وهيكل من الوحدات النمطية والخدمات. هناك هندسة تحجيم التطبيق ، وبنية موثوقية التطبيق ، وبنية تفاعل المكونات ، وبنية الأمان. وبالطبع ، كل ميزة لها هندستها المعمارية الخاصة. وكل هذا معًا هو أيضًا الهندسة المعمارية.
هل يمكن اعتبار كل هذا إجابة على سؤال "ما هي العمارة؟" - ربما نعم. يبدو أن كل شيء على ما يرام ، ويبدو أن كل شيء واضح. ولكن هل هذه الإجابة مفيدة عمليًا ، شيء يمكن استخدامه في سير عمل حقيقي؟ ليس صحيحا.
كيف تعرف ما إذا كان القرار مهمًا أم أساسيًا؟ ما هي التحديات العالمية؟ ماذا يعني ذلك باهظ الثمن أو رخيص؟ كيف تقدر التعقيد؟ أين الحد الفاصل بين المستوى العالي والمنخفض؟ ما هو النظام؟ ما هو الغرض من النظام؟
هذه كلها أسئلة يمكنك أيضًا محاولة الإجابة عليها. صياغة التعريفات ، والشرح بالأمثلة ، في أسوأ الأحوال ، تنظيم عملية صنع القرار. لكنه سيظل شيئًا مثيرًا للجدل ، شيئًا بديهيًا ، يعتمد على الإدراك الشخصي ويفهمه الجميع قليلاً بطريقتهم الخاصة. هذا يعني أنه ستكون هناك دائمًا صراعات تستند إلى حقيقة أن الأشخاص المختلفين يفسرون نفس الموقف بشكل مختلف جذريًا. سوف يشكو المطورون من أن المهندسين المعماريين يعبثون بتفاصيل التنفيذ ، المهندسين المعماريين من أن المطورين يكسرون الهندسة المعمارية. إذا لم تكن هناك حدود واضحة ، فإن النزاعات لا مفر منها.
ربما يكون لدى الجميع بعض الفهم العام لماهية العمارة. لكن من الصعب تسمية تعريف واحد تم التحقق منه رسميًا ودقيقًا رياضيًا.
من ناحية أخرى ، إذا سألت "ما هو الإدراك؟" - من المحتمل أن تكون الإجابة واضحة: "هذا رابط إلى مستودع الكود!" ولا يمكنك المجادلة في ذلك. ولا شك أو غموض في تفسير هذه الإجابة. 1 + 1 = 2 ، التنفيذ هو رمز.
والعمل مع الكود بسيط للغاية. إذا كنت تريد فهم التنفيذ ، يمكنك فتح المشروع في بيئة التطوير. إذا كانت التغييرات في الكود بحاجة إلى المراجعة ، فهناك فروع في المستودع. إذا حان الوقت لإصدار إصدار جديد من التطبيق ، فسيتم إطلاق الاختبارات.
بالطبع ، يمكن أن يكون هيكل المشروع مربكًا ، والمراجعات ذات جودة رديئة ، وتغطية الاختبار غير مكتملة. ولكن ، على الأقل عند العمل باستخدام الكود ، يكون من الواضح تمامًا ماذا ومتى يجب القيام به.
ولكن ماذا لو تم التعبير عن العمارة في كود ، تمامًا مثل التنفيذ؟
يتم استخدام العديد من لغات البرمجة السائدة في التطوير الحديث. ظهر معظمهم منذ فترة طويلة أو منذ فترة طويلة جدًا. وعلى الرغم من أنها لا تزال جيدة ، إلا أنها أصبحت قديمة بعض الشيء. هذه لغات مكتوبة بشكل ضعيف: JavaScript و Python و PHP و Ruby واللغات المكتوبة بشدة: Java و C / Objective-C / C ++ و C #. يتم استبدالها بلغات جديدة ، في إطار نفس النظام الأساسي ، تحاول حل المشكلات طويلة الأمد ، ورشها بالسكر النحوي ، ولكن دون تقديم مفاهيم جديدة بشكل أساسي ، إذا نظرت عالميًا: Swift ، Kotlin ، TypeScript ، Go. هذه كلها لغات مبنية على النموذج الموجه للكائنات. أيضًا ، اكتسب النهج الوظيفي للبرمجة شعبية ناضجة ، والتي يتم تنفيذها باللغات المدرجة وتقديمها بلغات متخصصة ، ولكنها أقل شيوعًا: Erlang، F #.كما بدأت اللغات التي تطبق مفاهيم جديدة بشكل كبير في اكتساب شعبية: روست ، هاسكل.
كل هذا التنوع يشترك في شيء واحد: جميعها لغات تنفيذ. لا تعتبر أي من لغات البرمجة هذه تعبيرات عن العمارة. ولكن هناك استثناء واحد - SQL.
SQL هي لغة البرمجة السائدة الوحيدة التي تعتبر تعريفية. إنه مبني على نموذج الجبر العلائقي وله تخصص ضيق - العمل مع البيانات المخزنة. ولكن مع ذلك ، لماذا يمكن اعتبار SQL لغة العمارة؟
بادئ ذي بدء ، يوفر SQL الوصول إلى المعلومات الوصفية حول مخطط البيانات. يمكنك بسهولة الحصول على قائمة بالجداول والأعمدة والعلاقات والفهارس وطرق العرض والأدوار والمزيد من قاعدة البيانات. يعد توثيق مخطط التخزين والقدرة على تصوره مساعدة كبيرة في فهم بنية التطبيق الخاص بك. وصف مخطط البيانات هو نوع من وصف البنية عالية المستوى.
ثانيًا ، يوفر SQL لغة استعلام بيانات تسمح للعميل بالاستعلام عن أي مجموعة من البيانات الموضحة في المخطط. إذا لم تكن هناك لغة استعلام ، فبالنسبة لكل نموذج بيانات مطلوب من قبل العميل ، يجب إما تنفيذ طريقة API منفصلة ، أو يتعين على العميل إجراء عدة استدعاءات API لأجزاء مختلفة من مخطط البيانات والجمع بين النموذج المطلوب من جانبه. يسمح وجود لغة الاستعلام بالاستبعاد من وصف تفاصيل تنفيذ الهندسة المعمارية المرتبطة بتعداد طرق API للحصول على نماذج بيانات محددة وفقًا للمخطط العام. تستثني لغة الاستعلام تفاصيل التنفيذ من وصف العمارة.
يوفر SQL ثلاث خصائص رئيسية مهمة لوصف العمارة:
- التصريح - يسمح لك SQL بفصل وصف الهندسة المعمارية عن تنفيذها.
- قابلية التحليل - يوفر SQL الوصول إلى المعلومات الوصفية لمخطط البيانات ، مما يسمح لك بتصور تمثيلاته وتوثيقها وتحليلها.
- التصحيح - يسمح لك SQL بتحديد قيود نموذج البيانات ، مما يجعل من الممكن منع انتهاكات سلامة البيانات المختلفة من خلال التنفيذ.
ربما ، يمكن تسمية SQL كأداة لوصف الهندسة المعمارية من حيث تخزين البيانات ، ولكن من الواضح أنه لا يكفي وصف البنية الكاملة للمنتج.
وسائل أخرى لوصف العمارة
التناظرية المباشرة لـ SQL هي GraphQL ، والتي تتيح لك أيضًا تحديد مخطط البيانات وتوفير الوصول إليها من خلال لغة الاستعلام. في الوقت نفسه ، تم بناء GraphQL على نظرية الرسم البياني ، وليس على نموذج الجبر العلائقي. هذا يجعل من الممكن العمل مع نماذج البيانات الهرمية بطريقة أكثر طبيعية ، على عكس SQL ، حيث قد يكون العمل مع التسلسلات الهرمية أمرًا صعبًا.
غالبًا ما يتم الترويج لـ GraphQL كحل اتصال بين الخادم والعميل ، ولكن هذا ليس المجال الوحيد لتطبيقها. وبالمثل ، من خلال GraphQL ، يمكنك توفير الاتصال من خادم إلى خادم ، وحتى الاتصال من خادم إلى قاعدة. إن حقيقة أن قواعد البيانات الحديثة توفر فقط واجهة SQL ، ولكنها لا توفر واجهة برمجة تطبيقات ملائمة للعمل مع الاستعلامات الهرمية هو إغفال مهين.
إذا كانت SQL وسيلة لوصف بنية مخطط تخزين البيانات ، فإن GraphQL تتيح لك وصف بنية مخطط البيانات بالفعل على مستوى الأعمال ، من حيث منطقة تطبيق معينة. بهذا المعنى ، تسمح لك GraphQL بتعريف البنية على مستوى أعلى ، أقرب إلى منطقة التطبيق الحقيقية للمنتج.
تعد وحدات الكود النمطية والخدمات المصغرة ، جنبًا إلى جنب مع واجهات برمجة التطبيقات والتبعيات الخاصة بها ، أدوات للتعبير عن الهندسة المعمارية من حيث الهيكل والعلاقات.
العمارة والتنفيذ
بالنسبة لمشروع صغير يعمل عليه عشرات المطورين ، غالبًا ما لا يلزم وصف منفصل للهندسة المعمارية. إذا تمت كتابة كود المشروع بدقة وبتنظيم جيد ، فقد يكون هذا كافيا لفهم الصورة العامة واتجاهات التنمية.
مع نمو المشروع ، تظهر وثائق مختلفة تصف بنيته العامة وتفاصيل الأجزاء الجديدة والتحسينات الرئيسية. هذا نهج عملي تمامًا عندما يعمل عشرات الأشخاص في مشروع ما.
لكن بالنسبة لمشروع كبير إلى حد ما ، عندما يكون هناك مئات المطورين ، يبدأ هذا النهج بالفشل. هناك عدد كبير جدًا من المستندات ، ويبدأ محتواها في التباعد أكثر فأكثر عن التنفيذ. يصبح من الصعب أكثر فأكثر التعبير عن الأفكار بنفس الطريقة للجميع. يتم تنظيم التجمعات لعشرات الأشخاص لمناقشة العديد من الموضوعات الخاصة ، بينما يمكن تنفيذ التغييرات المهمة حقًا دون أي مناقشة على الإطلاق. كل هذا يؤدي إلى الحاجة إلى تنظيم المزيد والمزيد من العمليات ، عندما يتعين على البعض تقديم شيء ما ، يتبعه الآخرون ، ويراجع الآخرون ، ولا يزال البعض الآخر يفعل. بيروقراطية. نتيجة لذلك ، بدأ المطورون في كتابة المزيد من المستندات ورموز أقل ، وهذه ليست المشكلة الأكثر أهمية.
بالطبع ، لا حرج في البيروقراطية في حد ذاتها. في أي عمل ، تنظيمها مهم. المشكلة هي مقدار البيروقراطية لكل وحدة عمل مفيد. إذا كنت تريد عقد اجتماعين آخرين أو ثلاثة أو أربعة أو خمسة ، من أجل إنشاء واحد ، فهذا لم يعد جيدًا في أي مكان.
حتى السؤال البسيط عن التغيير الذي يمكن للمطور إجراءه بنفسه ، لأن هذا هو تنفيذ ، وما هو المطلوب لتقديم طلب للمراجعة ، لأن هذه بنية ، يبدأ في التسبب في صعوبات. يجب عليك التوصل إلى مجموعة متنوعة من المشغلات المعمارية ، بحيث إذا قمت بتغيير مخطط البيانات أو تناولت قضايا التشفير والأمان ، فيجب مراجعة هذا بشكل معماري ، ويبدو أن الموضوعات الأخرى ليست كذلك ، ولكن هذا ليس مؤكدًا. كل هذا لا يحتاج فقط إلى صياغة وشرح لمئات المطورين ، ولكن أيضًا لضمان اتباع القواعد الموصوفة. مثل هذه العملية ستفشل باستمرار.
كل هذه المشاكل مرتبطة بعدم وجود تعريف واضح للعمارة.
مثلما يشير تغيير ملف ".java" في المستودع بشكل لا لبس فيه إلى حدوث تغيير في التنفيذ ، فإن تغيير ملف ".architecture" يمكن أن يشير إلى تغيير في البنية. بالطبع ، ملفات ".architecture" غير موجودة في الطبيعة. لكن بالنسبة لكل مشروع ، يمكنك تحديد الجوانب المحددة منه المتعلقة بهندسته ، وجعلها واضحة.
إذا كان التغيير في مخطط البيانات يعتبر تغييرًا في البنية ، فيجب أن تشير الملفات التي تحتوي على عمليات ترحيل SQL إلى البنية. إذا كانت واجهة برمجة التطبيقات أيضًا جزءًا من الهندسة المعمارية ، فيمكنك تحديد واجهة برمجة التطبيقات في شكل نفس ملفات التباهي والاعتماد عليها. إذا كان هيكل الوحدات هو الهندسة المعمارية ، فإن التغيير في وصف الوحدات هو تغيير معماري. إلخ.
لا يمكن التعبير عن جميع جوانب العمارة بالوسائل القياسية. كل مشروع له تفاصيله الخاصة. على سبيل المثال ، إذا كان المنتج يستخدم نموذجًا محددًا للحقوق ، والأدوار ، وأنواع الاشتراكات ، والإضافات ، وما إلى ذلك ، فعليك التفكير في تحديد بنية هذا الجانب من المنتج في شكل إعلاني مناسب ، وبالتالي إبراز جوهر البنية من تفاصيل التنفيذ. بالطبع ، قد تتطلب مثل هذه التغييرات إعادة صياغة التعليمات البرمجية بشكل كبير. ولكن هذا استثمار أفضل بكثير في تحديد بنية المنتج من محاولة وصف نموذج الحقوق في مستند.
التمثيل الرسمي للهندسة المعمارية في الكود ممكن ، وهذا فقط يعطي تعريفًا واضحًا لماهية العمارة. يتيح هذا العرض إمكانية تحليل البنية وإنشاء وثائق عليها تلقائيًا ، والتي ستكون دائمًا محدثة. كل ما تبقى: وثائق ورسوم بيانية ومخططات مرسومة باليد - بيروقراطية.
يمكن أن يكون للعمارة تعبير رسمي في الكود ، وهذا فقط يحدد حدًا واضحًا بين العمارة والتنفيذ. ومثل هذه الحدود مطلوبة.
المناهج الهندسية والتطورية في العمارة
على مدى نصف القرن الماضي ، قطعت صناعة التطوير شوطًا طويلاً من نماذج الشلال إلى التطوير التكراري. والآن يبدو أن الصناعة قد ذهبت بعيداً في هذا الأمر. في بعض الأماكن ، لم يعد عمل المهندس المعماري يشبه عمل مهندس أو حتى بستاني ، ويبدأ أكثر فأكثر في التشابه مع عمل عامل موسمي يتم تعيينه لغرض وحيد هو إزالة الأعشاب الضارة من الأعشاب الضارة.
ما يميز الهندسة عن الحرفة هو فهم قوانين الطبيعة ، والنظاميات التي يمكن على أساسها إجراء الحسابات والاستنتاجات ، وتصميم الحلول ، وليس التجربة. يمكن لأي نجار أن يصنع كرسيًا مقبولًا تمامًا ، ولكن المعرفة الهندسية مطلوبة لجعل البراز مثاليًا: خفيف وموثوق ومستقر وبسيط ورخيص التصنيع. يتيح لك الأسلوب الهندسي الحصول على أفضل نتيجة بسرعة وبأقل جهد. لسوء الحظ ، في تطوير البرمجيات ، لا يكون النهج الهندسي ممكنًا دائمًا.
في كثير من الأحيان ، تكون النتيجة التي يرغب المرء في تحقيقها مُحددة بشكل غامض للغاية ، والعديد من العوامل التي تؤثر بشكل كبير على بنية الحل غير واضحة أو غير معروفة على الإطلاق ، ويمكن أن يكون العمل على تنفيذ الحل نفسه أسرع وأرخص من التفصيل التفصيلي لهيكله. هذا هو أحد الأسباب التي جعلت النهج التكراري للتنمية قد اكتسب هذه الشعبية. في بعض الأحيان يتجاوز القياس.
في أسوأ الحالات ، يمكن أن يتلخص تطوير الهندسة المعمارية في حقيقة أن كل فريق تطوير يعطي ببساطة مراجعة للمهندس ووصفًا لما سينفذونه. في مثل هذه الحالة ، يتم تقليل عمل المهندس إلى إزالة الأعشاب الضارة. وهنا أنت لم تنسى؟ هل أخذت هذا في الاعتبار؟ وهنا الخطأ. هل تريد إضافة فهرس هنا؟ وهكذا التكرار بعد التكرار.
من الضروري إزالة الأعشاب الضارة. ولكن كيف ستكون الحديقة إذا فعلت هذا فقط؟ سوف تذبل أحواض الزهور في ظل أشجار الفاكهة ، وسوف تتناوب الفراولة والجزر ، وسيتم اجتياز كل هذا من خلال مسارات لا حصر لها تضيع المساحة المتاحة. من الصعب الحديث عن أي هندسة معمارية هنا.
لكي تظهر العمارة ، يجب على المهندس المعماري أن يقوم بعمل بستاني على الأقل. يجب أن تزرع التوت والخضروات بشكل منفصل - الهيكل ، والمكان الذي يذهب إليه الناس في أغلب الأحيان ، تحتاج إلى وضع مسارات - وصلات. من خلال مراقبة التفاصيل ، يمكن للمهندس أن يتصرف بشكل استباقي ، وينظم وينظم السمات الخاصة التي تنشأ في عملية الإدراك في هيكل واحد. مثل تصميم المناظر الطبيعية ، يمكن للمهندس أن يشكل المسار الطبيعي للأحداث ، ويعزز الاتجاهات الإيجابية ويمنع الاتجاهات السلبية.
وهنا نحتاج إلى تعريف واضح للعمارة في الكود. مخططات البيانات ، وهياكل الوحدات النمطية والخدمات ، وواجهة برمجة التطبيقات وقواعد التفاعل. بدون تحديد هذه الأدوات ، إما أن يتورط المهندس المعماري في مراجعة التنفيذ أو يأمل بسذاجة أن يتبع المطورون القواعد الموضحة في بعض المستندات ، والتي لن تحدث بالطبع.
إذا كان هناك عرض تقديمي رسمي للهندسة المعمارية وقواعد تغييراتها ، فيمكن بالفعل تسمية هذا النهج التطوري لتطوير العمارة. وهذا ليس سيئا. لكن هل يجب أن نقتصر على هذا؟
نعم ، قد تبدو المتطلبات غامضة في البداية ، وقد تبدو العوامل غامضة ، والنظام نفسه معقد للغاية بحيث يسهل القيام به بدلاً من التصميم. لكن بمرور الوقت ، بدأت هذه الأشياء تتضح. مع الخبرة العملية في تطوير الهندسة المعمارية ، تظهر تفاصيل تنظيم منطقة التطبيق أكثر وأكثر وضوحًا. يتضح أن هذا الحل العام يتم تنفيذه بخمس طرق مختلفة ، وأن المستخدمين يعانون من هذا التنوع. أن بعض الأشياء في غير محلها وتحتاج إلى نقلها ، في حين أن البعض الآخر قد عفا عليه الزمن بالفعل واستبداله بحلول جديدة ، لذلك يجب إزالتها. وتتوقف التطورات الجديدة عن الظهور بمظهر جديد - وقد قمنا بالفعل بتنفيذ هذا وذاك. هل تتذكر ما أدى كل هذا؟ لنفعل ذلك على الفور حتى لا نضطر إلى إعادته لاحقًا. بعد كل شيء ، القيام بذلك بشكل صحيح في وقت واحد عادة ما يكون أسرع من اللازم.لكن هذا فقط إذا كنت تعرف حقًا كيفية القيام بذلك بشكل صحيح. ومع الخبرة ، غالبًا ما يأتي هذا الفهم.
العمارة الجيدة ليست شيئًا نما من تلقاء نفسه ثم أصبح منظمًا قليلاً ، ولكنه شيء كلي ومتناسق وعضوي. من الممكن اتباع نهج هندسي لتطوير العمارة ، مجرد فهم القواعد والأنماط قد يستغرق بعض الوقت.
لا يجب أن يكون التعريف الرسمي للهندسة المعمارية لمشروع معين ثابتًا. يمكن الإعلان عن طرق واجهة برمجة التطبيقات التي تم إيقافها على أنها مهملة ، ويمكن الإعلان عن الطرق المفقودة على أنها لم يتم تنفيذها. يمكن تمييز الأجزاء ذات المعنى من الكود لوضعها في وحدات منفصلة. يمكنك التخطيط لتقسيم الجدول إلى قسمين ، أو نقلهما إلى قاعدة بيانات أخرى. إلخ. يمكن تغيير البنية دون تغيير التنفيذ. سوف التنفيذ اللحاق بالركب. وللمواكبة بشكل أسرع ، يمكن أتمتة العملية قليلاً عن طريق عمل تذكيرات تلقائية في محادثات الفريق. بنفس الطريقة ، يمكن للتغييرات التي أجراها المطورون في الملفات المعمارية أن تنتقل تلقائيًا إلى دردشة الفريق المعماري.
من الممكن اتباع نهج هندسي لتطوير العمارة.
في الوقت نفسه ، لا ينبغي للمرء أن يفترض أن عمل المهندس المعماري هو في الأساس أفضل أو أسوأ من عمل المطور. إنها مختلفة فقط. يعمل المطور ، أولاً وقبل كل شيء ، بأسلوب الأمر ، بينما يكون عمل المهندس المعماري أكثر وضوحًا. يحدث أنه من الصعب العمل على الهيكل ، لكن التنفيذ هو أمر روتيني. كما يحدث العكس بالعكس.
والهندسة المعمارية والتصميم
غالبًا ما يتم استخدام مصطلحات الهندسة المعمارية والتصميم بالتبادل. يمكنك أن تقول: هندسة النظام أو تصميم النظام. بشكل عام ، من الواضح ما هو هذا. ومع ذلك ، هناك اختلافات كبيرة في هذه الشروط.
التصميم ، أولاً وقبل كل شيء ، يعني شيئًا مرئيًا ، شيء يمكن تخيله أو رؤيته. المخططات والرسوم البيانية والنماذج. يسمح لك التصميم بإظهار العلاقة بين الكيانات بشكل مرئي ، وتتبع سلاسل التفاعل ، ورؤية الاختلافات والتماثلات الهيكلية.
لكن الهندسة المعمارية ليست بصرية فقط ، بل يمكن أن تشمل القواعد والقيود والاستدلالات والحسابات الرياضية. المفاهيم السيئة التصور.
بالطبع ، كلاهما مهم.
من الجيد أن يتم تحديد الجوانب المهمة للهندسة المعمارية بوضوح في الكود. لكن هذا لا يكفى. من المهم جعل العمارة مرئية والمبادئ المتأصلة فيها تلقائية.
إذا كانت الهندسة المعمارية تتضمن مخطط بيانات ، فيجب أن يكون هناك تمثيل مرئي لها. الوحدات النمطية لها تبعيات - يجب أيضًا تقديمها. إذا كان هناك API ، فيجب أن تكون هناك وثائق مرتبطة مباشرة بهيكل الخدمات. إلخ. التصميم هو تمثيل مرئي للعمارة.
إذا كان للبنية مبادئ معينة ، على سبيل المثال ، "يمكن لتطبيقات العميل الوصول فقط إلى أنواع معينة من الخدمات المصغرة ، ولكن ليس جميعها" ، فعندئذٍ إذا كان هناك نموذج اتصال ، فيمكن التحقق منها تلقائيًا. وبالمثل ، يمكنك التحكم في الروابط بين الخدمات المصغرة وقواعد البيانات. إذا كانت هناك قواعد معينة لتصميم نماذج البيانات ، نفس القواعد لتسمية الجداول ، فيمكن أيضًا التحقق منها تلقائيًا. في التطوير ، يتم استخدام عمليات التحقق من الكود التلقائي ، ويمكن القيام بنفس الشيء بالنسبة للهندسة المعمارية. يمكنك كتابة اختبارات تلقائية على الهندسة المعمارية.
خاتمة
المطور الحديث لديه مجموعة كبيرة من الأدوات الرائعة المتاحة لتسهيل عمله. بيئات التطوير ، وبناء الأنظمة ، والمكتبات والأطر المختلفة ، وخدمات البنية التحتية والحاويات. لا يكتب المطورون تعليمات برمجية في Notepad.
الهندسة المعمارية هي أيضًا رمز ، وللعمل مع الهندسة المعمارية ، هناك مجموعة أدوات قوية وغنية مثل العمل مع التنفيذ. محرر مستندات Google ليس الأداة المعمارية الوحيدة التي يمكنك استخدامها ، وهي بعيدة كل البعد عن كونها الأفضل. بالطبع ، مجموعة الأدوات الجاهزة المتاحة للمهندس المعماري في الوقت الحالي ليست واسعة مثل مجموعة أدوات المطور. وليس كل ما يمكن للمهندس أن يستخدمه يعمل خارج الصندوق. ومع ذلك ، فإن الأمور ليست بهذا السوء.
توجد العديد من الأدوات منذ عقود ، مثل SQL ، ما عليك سوى تعلم كيفية استخدامها بشكل صحيح. بدأت التقنيات الجديدة مثل GraphQL في اكتساب شعبية ، وهي تقدم الأمل في أن تصبح مهمة وصف مجال الأعمال روتينية بمرور الوقت مثل وصف مجال التخزين. تتوفر أدوات لتوثيق وتصور بنية التطبيق وواجهة برمجة التطبيقات ، بما في ذلك Swagger. يمكنك استخدام نفس الأطر وأدوات التكامل لاختبار البنية كما تفعل لاختبار التنفيذ.
العمارة - التصريحية. من المحتمل أن بيروقراطية العمل مع المستندات لن تختفي تمامًا من عمل المهندس المعماري ، ولكن الآن يمكن تقليل حجمها بشكل كبير. الهندسة المعمارية هي أيضًا رمز ، وبمرور الوقت ، يمكن أن تصبح الأدوات المتاحة للعمل على الهندسة المعمارية متقدمة مثل أدوات العمل على التنفيذ. سنرى.
-
ديمتري
مامونوف ، وريك
ب. س. لقد بدأت المقالة بقائمة من الأسئلة الفلسفية التي آمل أن أتمكن من إعطاء إجابات محددة عليها. على الأقل هذه وجهة نظري. هل وجدت شيئًا مفيدًا أو جديدًا في المقال؟ كيف تجيب بنفسك على هذه الأسئلة؟ اكتب في التعليقات.