القرارات المعمارية

الدرس 16 من 38 · فهم المشكلة · 6 دقيقة و55 ثانية

الفيديو الأصلي باللغة الإنجليزية. إذا تعذّر تشغيله هنا، شاهده على موقع المؤلف. التفريغ النصي العربي الكامل أدناه.

الموارد

• شرائح الفيديو
• قالب: قالب ADR بسيط بواسطة مايكل Nygard
• المادة: توثيق القرارات المعمارية بواسطة مايكل Nygard
• ADR 1: استخدام Next.js لتطبيق ويب عميل FullSnack

التفريغ النصي

[00:03] آخر شيء سنغطيه في هذه الوحدة هو مفهوم القرارات المعمارية. كما قد تتذكر، هذه هي القرارات التي تقع أكثر نحو نهاية المعمارية من الطيف. وقد يكون ذلك لأن هذه القرارات هنا تتعلق بهيكل النظام، أو يصعب تغييرها، أو لها آثار على المدى الطويل.

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

[01:04] ثم لدينا، على سبيل المثال، اتخاذ القرارات حول التحكم في الإصدار. هل نريد استخدام repo أحادي أم أننا نريد استخدام عدد كبير من repos ونشرها في سجل NPM خاص، على سبيل المثال؟ هذه قرارات قد نرغب على الأقل في وضعها في الاعتبار أن هذه المراحل المبكرة قد نرغب في اتخاذ قرارات حول كيفية الحفاظ على تنظيم قاعدة الشيفرة. ربما يكون هذا قرارًا قد نرغب في القيام به لاحقًا، ولكن في مرحلة ما يجب أن نحدد ما إذا كنا نريد استخدام طريقة معينة للتنظيم مثل التصميم المدفوع بالمجال أو المعمارية النظيفة، أم أننا نريد استخدام ذلك حصلت على أكثر مثل التسلسل الهرمي البسيط للحفاظ على مكوناتنا المنظمة.

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

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

[03:11] لذلك في مشروعنا، على سبيل المثال، سنتخذ قرار استخدام Next.JS لإطار الواجهة الأمامية لدينا. الآن، لا تقلق، إذا لم تكن لديك خبرة في Next.JS أو حتى إذا كنت لا تحب Next على الإطلاق، فسيكون لها تأثير صغير جدًا في بقية الدورة. ولكن الأهم من ما هو القرار، والذي يستخدم Next.JS. نعم، هو لماذا نتخذ هذا القرار والقيام بذلك وسيلة رائعة لتوثيق لماذا يستخدم أداة تسمى سجلات القرارات المعمارية أو ADRs

[03:44] ADRs تسمح لنا لتوثيق قراراتنا الهامة معماريا. وبمرور الوقت، كل من ADRs لدينا سوف تشكل نوعا من سجل القرارات المعمارية. وهذا السجل سيكون مثل كتاب يحكي قصة عمارتنا. لذلك بالنسبة لـ ADRs، أحب استخدام هذا القالب البسيط للغاية بواسطة Michael Nygard، والذي ستجده في الوصف أدناه. وأساسا لديها عدد قليل من الأقسام. لدينا عنوان لـ ADR. لدينا وضع قد يكون شيئًا مثل التقدم أو القبول أو المسودة وما إلى ذلك. لدينا بعض السياق حول ما هو القرار، لماذا يجب علينا اتخاذ هذا القرار، ما هو القرار والعواقب، الإيجابية والسلبية.

[04:31] لذلك دعونا ننظر إلى مثال، ADR لدي هنا حول القرار الذي تحدثنا عنه سابقًا حول استخدام Next.JS نعم، لـ FullSnack. لذلك لدينا العنوان هنا وعادة ما يكون من الممارسات الجيدة أيضًا تسمية أو الحصول على معرف، مثل مجرد رقم بسيط لـ ADR الخاص بنا حتى نتمكن من إحالتهم باستخدام هذه الهوية هنا. ثم لدينا الوضع. تم قبوله لأنني الشخص الوحيد الذي يعمل في هذا المشروع. لذلك كتبت ADR وقبلت على الفور. ومن ثم لدينا السياق حول لماذا علينا أن نتخذ هذا القرار لبناء الجديد. نحن بحاجة إلى إطار جديد لواجهة المستخدم لهذا التطبيق الجديد الذي نبنيه ونرغب في إنشاء التزام قوي وقابل للتطوير وأداء. لدينا جدول زمني ضيق جدا من أربعة أشهر.

[05:16] إليك ما هو القرار، وهو استخدام Next.JS كإطار عملنا واستضافته على البنية التحتية AWS الخاصة بنا باستخدام SST. الآن لا تقلق إذا كنت لا تعرف ما هو SST، إنها مجرد أداة تسمح لنا بالنشر على تطبيق Next.JS أو ASTRO أو أنها تدعم العديد من الأطر الأخرى على البنية التحتية AWS الخاصة بك، والتي أفترض أنك تتذكر أن هذا أحد القيود التي واجهناها. ثم لدينا عواقب هذا القرار. تشمل العواقب الإيجابية التطور السريع لأن جميع أعضاء الفريق على دراية بالفعل بـ Next.JS لذلك نحن نحد من مخاطر اتخاذ إطار جديد لا يعرفه أحد. لذلك نحن نحد من المجهولات التي لا نعرف بوجودها بطريقة تسمح لنا بالتحرك بسرعة والوفاء بموعدنا النهائي الضيق. ولدينا عواقب إيجابية أخرى مثل مرونة التنمية وحقيقة أن Next.JS لديها مجتمع كبير ونظام بيئي، على سبيل المثال، ثم لدينا بعض العواقب السلبية أيضًا، والتي تعد أيضًا فكرة جيدة للتوثيق.

[06:17] الآن مرة أخرى، هذا مجرد مثال على ADR، ويمكنك استخدامه كقالب لـ ADRs الخاصة بك. لكن النقطة المهمة هي أنه من الجيد دائمًا توثيق القرارات المهمة. إذا كان شخص ما سيطرح سؤالًا في المستقبل حول سبب اتخاذ شخص ما لهذا القرار أو لماذا أنت كمعماري اتخذ القرار، فمن الجيد أن يكون لديك وثيقة مثل هذه ستخبرهم بالسبب بالضبط.

[06:41] ومع ذلك، وصلنا إلى نهاية وحدة التفاهم. نأمل في هذه المرحلة أن يكون لديك فهم جيد وفهم قوي لما هي المشكلة التي نحلها. وفي الوحدة التالية، عندما أتوصل إلى حل جيد لذلك.