Architecture Decision Recordתהליך רשומות החלטה ארכיטקטוניות של AWS
רשומת החלטה ארכיטקטונית (ADR) היא מסמך שמתאר בחירה שהצוות עושה לגבי היבט משמעותי של ארכיטקטורת התוכנה שהוא מתכנן לבנות. כל ADR מתארת את ההחלטה הארכיטקטונית, את ההקשר שלה ואת תוצאותיה. ל-ADR יש מצבים, ולכן היא עוברת מחזור חיים. לדוגמה של ADR, ראו את הנספח.
תהליך ה-ADR מפיק אוסף של רשומות החלטה ארכיטקטוניות. האוסף הזה יוצר את יומן ההחלטות. יומן ההחלטות מספק את הקשר הפרויקט וכן מידע מפורט על מימוש ועיצוב. חברי הפרויקט סורקים את הכותרות של כל ADR כדי לקבל סקירה כללית של הקשר הפרויקט. הם קוראים את ה-ADR כדי להעמיק במימושי הפרויקט ובבחירות העיצוב.
כשהצוות מקבל ADR, היא הופכת לבלתי ניתנת לשינוי. אם תובנות חדשות מחייבות החלטה אחרת, הצוות מציע ADR חדשה. כשהצוות מקבל את ה-ADR החדשה, היא מחליפה את ה-ADR הקודמת.
היקף תהליך ה-ADR
חברי הפרויקט צריכים ליצור ADR לכל החלטה בעלת משמעות ארכיטקטונית שמשפיעה על פרויקט או מוצר התוכנה, כולל הבאים (Richards and Ford 2020):
מבנה (לדוגמה, תבניות כמו מיקרו-שירותים)
דרישות לא פונקציונליות (אבטחה, זמינות גבוהה וסבילות לתקלות)
תלויות (צימוד בין רכיבים)
ממשקים (ממשקי API וחוזים שפורסמו)
טכניקות בנייה (ספריות, מסגרות, כלים ותהליכים)
דרישות פונקציונליות ולא פונקציונליות הן הקלט הנפוץ ביותר לתהליך ה-ADR.
תוכן ה-ADR
כשהצוות מזהה צורך ב-ADR, חבר צוות מתחיל לכתוב אותה על בסיס תבנית אחידה לכל הפרויקט. (ראו את ארגון ה-ADR ב-GitHub לדוגמאות של תבניות.) התבנית מפשטת את יצירת ה-ADR ומבטיחה שה-ADR תכלול את כל המידע הרלוונטי. לכל הפחות, כל ADR צריכה להגדיר את הקשר ההחלטה, את ההחלטה עצמה ואת תוצאות ההחלטה עבור הפרויקט ועבור התוצרים שלו. (לדוגמאות של הסעיפים האלה, ראו את הנספח.) אחד ההיבטים החזקים ביותר במבנה ה-ADR הוא שהוא מתמקד בסיבה להחלטה ולא באופן שבו הצוות מימש אותה. הבנה של הסיבה שבגללה הצוות קיבל את ההחלטה מקלה על חברי צוות אחרים לאמץ אותה, ומונעת מאדריכלים אחרים שלא היו מעורבים בתהליך קבלת ההחלטות לבטל אותה בעתיד.
תהליך אימוץ ה-ADR
כל חבר צוות יכול ליצור ADR, אבל הצוות צריך לקבוע הגדרה של בעלות על ADR. כל מחבר שהוא הבעלים של ADR צריך לתחזק ולהעביר באופן פעיל את תוכן ה-ADR. כדי להבהיר את הבעלות הזו, המדריך הזה מכנה את מחברי ה-ADR בעלי ADR בסעיפים הבאים. חברי צוות אחרים יכולים תמיד לתרום ל-ADR. אם תוכן ה-ADR משתנה לפני שהצוות מקבל אותה, הבעלים צריך לאשר את השינויים האלה.
אחרי שהצוות מזהה החלטה ארכיטקטונית ואת הבעלים שלה, בעל ה-ADR מגיש את ה-ADR במצב מוצעת (Proposed) בתחילת התהליך. ADR במצב מוצעת מוכנות לסקירה.
בעל ה-ADR מתחיל אז את תהליך הסקירה של ה-ADR. מטרת תהליך סקירת ה-ADR היא להחליט אם הצוות מקבל את ה-ADR, קובע שהיא דורשת עבודה נוספת, או דוחה אותה. צוות הפרויקט, כולל הבעלים, סוקר את ה-ADR. פגישת הסקירה צריכה להתחיל בפרק זמן ייעודי לקריאת ה-ADR. בממוצע, 10 עד 15 דקות אמורות להספיק. במהלך הזמן הזה כל חבר צוות קורא את המסמך ומוסיף הערות ושאלות כדי לסמן נושאים לא ברורים. אחרי שלב הסקירה, בעל ה-ADR מקריא ודן עם הצוות בכל הערה.
אם הצוות מוצא פעולות לשיפור ה-ADR, מצב ה-ADR נשאר מוצעת. בעל ה-ADR מנסח את הפעולות, ובשיתוף עם הצוות מוסיף אחראי לכל פעולה. כל חבר צוות יכול לתרום ולסגור את הפעולות. באחריות בעל ה-ADR לתזמן מחדש את תהליך הסקירה.
הצוות יכול גם להחליט לדחות את ה-ADR. במקרה כזה בעל ה-ADR מוסיף סיבה לדחייה כדי למנוע דיונים עתידיים באותו נושא. הבעלים משנה את מצב ה-ADR לנדחתה (Rejected).
אם הצוות מאשר את ה-ADR, הבעלים מוסיף חותמת זמן, גרסה ורשימת בעלי עניין. אז הבעלים מעדכן את המצב להתקבלה (Accepted).
ה-ADR ויומן ההחלטות שהן יוצרות מייצגים החלטות שהצוות קיבל ומספקים היסטוריה של כל ההחלטות. הצוות משתמש ב-ADR כהפניה בסקירות קוד וסקירות ארכיטקטורה במידת האפשר. בנוסף לביצוע סקירות קוד, משימות עיצוב ומשימות מימוש, על חברי הצוות להיעזר ב-ADR להחלטות אסטרטגיות עבור המוצר.
כנוהג טוב, כל שינוי בתוכנה צריך לעבור סקירת עמיתים ולדרוש לפחות אישור אחד. במהלך סקירת הקוד, סוקר הקוד עשוי למצוא שינויים שמפרים ADR אחת או יותר. במקרה כזה הסוקר מבקש ממחבר שינוי הקוד לעדכן את הקוד, ומשתף קישור ל-ADR. כשהמחבר מעדכן את הקוד, העמיתים הסוקרים מאשרים אותו והוא ממוזג לבסיס הקוד הראשי.
תהליך סקירת ה-ADR
הצוות צריך להתייחס ל-ADR כאל מסמכים בלתי ניתנים לשינוי אחרי שהצוות מקבל או דוחה אותן. שינויים ב-ADR קיימת מחייבים יצירת ADR חדשה, קביעת תהליך סקירה ל-ADR החדשה ואישורה. אם הצוות מאשר את ה-ADR החדשה, הבעלים צריך לשנות את מצב ה-ADR הישנה להוחלפה (Superseded).