فرایند رکورد تصمیم معماری AWS

https://docs.aws.amazon.com/prescriptive-guidance/latest/architectural-decision-records/adr-process.html

رکورد تصمیم معماری (ADR) سندی است که انتخابی را که تیم دربارهٔ یک جنبهٔ مهم از معماری نرم‌افزاری که قصد ساخت آن را دارد انجام می‌دهد، توصیف می‌کند. هر ADR تصمیم معماری، زمینه و پیامدهای آن را توصیف می‌کند. ADRها وضعیت دارند و بنابراین از یک چرخهٔ عمر پیروی می‌کنند. برای نمونه‌ای از ADR، پیوست را ببینید.

خروجی فرایند ADR مجموعه‌ای از رکوردهای تصمیم معماری است. این مجموعه گزارش تصمیمات را تشکیل می‌دهد. گزارش تصمیمات زمینهٔ پروژه و همچنین اطلاعات تفصیلی پیاده‌سازی و طراحی را فراهم می‌کند. اعضای پروژه برای دریافت مرور کلی زمینهٔ پروژه، سرفصل‌های هر ADR را از نظر می‌گذرانند. آن‌ها برای فرو رفتن عمیق در پیاده‌سازی‌ها و انتخاب‌های طراحی پروژه، ADRها را می‌خوانند.

وقتی تیم یک ADR را می‌پذیرد، تغییرناپذیر می‌شود. اگر بینش‌های جدید تصمیم متفاوتی را ایجاب کنند، تیم یک ADR جدید پیشنهاد می‌دهد. وقتی تیم ADR جدید را می‌پذیرد، جایگزین ADR قبلی می‌شود.

دامنهٔ فرایند ADR

اعضای پروژه باید برای هر تصمیم مهم از نظر معماری که بر پروژه یا محصول نرم‌افزاری تأثیر می‌گذارد، از جمله موارد زیر، یک ADR ایجاد کنند (Richards and Ford 2020):

• ساختار (برای مثال، الگوهایی مانند میکروسرویس‌ها)

• نیازمندی‌های غیرکارکردی (امنیت، دسترس‌پذیری بالا و تحمل خطا)

• وابستگی‌ها (جفت‌شدگی مؤلفه‌ها)

• رابط‌ها (API‌ها و قراردادهای منتشرشده)

• تکنیک‌های ساخت (کتابخانه‌ها، چارچوب‌ها، ابزارها و فرایندها)

• نیازمندی‌های کارکردی و غیرکارکردی رایج‌ترین ورودی‌های فرایند ADR هستند.

محتوای 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 را بازبینی می‌کند. جلسهٔ بازبینی باید با یک بازهٔ زمانی اختصاصی برای خواندن 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 جدید را تأیید کند، مالک باید وضعیت ADR قدیمی را به جایگزین‌شده (Superseded) تغییر دهد.