معماری نرم افزار – فصل سوم – بخش دوم

گرفتن یک تصمیم معماری

بحث‌کردن درباره‌ی مزایا و معایب با تیم، جلوی وایت‌برد، سرگرم‌کننده‌ست؛ ولی در نهایت باید یه تصمیم معماری بگیری.

ما قبلاً توی فصل اول درباره‌ی تصمیم‌های معماری صحبت کردیم، اما حالا می‌خوایم کمی عمیق‌تر بشیم. وقتی داری یه سیستم رو طراحی و معماری می‌کنی، باید کلی تصمیم بگیری—از ساختار کلی سیستم گرفته تا اینکه از چه ابزارها و تکنولوژی‌هایی استفاده بشه. پس چی باعث می‌شه یه تصمیم، «تصمیم معماری» حساب بشه؟

در بیشتر مواقع، هر انتخابی که ساختار سیستم رو تحت تأثیر قرار بده، یه تصمیم معماری محسوب می‌شه.

مثال:

• فکر می‌کنم تصمیم‌مون رو گرفتیم—قراره سرویس ارسال سفارش رو از سرویس پیگیری سفارش جدا کنیم.
• ما از کش استفاده می‌کنیم تا فشار روی پایگاه داده رو کم کنیم و عملکرد سیستم رو بهتر کنیم. دقت کن که این تصمیم یه بخش جدید به زیرساخت اضافه می‌کنه، و تیمی که قراره پیاده‌سازی کنه باید همیشه موقع خواندن یا نوشتن داده‌ها این موضوع رو در نظر داشته باشه.
• ما سرویس گزارش‌گیری رو به‌صورت یک مونولیت ماژولار (Modular Monolithic) طراحی خواهیم کرد. این یکی کاملاً واضحه—چون مستقیماً ساختار سرویس رو توصیف می‌کنه.

دقت کن که این تصمیم‌ها بیشتر نقش راهنما دارن تا قانون.
اونا به تیم‌ها کمک می‌کنن تا انتخاب‌های بهتری داشته باشن، بدون اینکه بیش‌ازحد جزئی بشن.
بیشتر (ولی نه همه‌ی) تصمیم‌های معماری‌ای که می‌گیری، حول ساختار کلی سیستم‌ات می‌چرخن.

یادداشت
همون‌طور که توی فصل اول گفتیم: «تصمیم‌های معماری مثل نشانه‌های راه هستن که به تیم‌های توسعه کمک می‌کنن محدودیت‌ها و شرایط معماری رو درک کنن.»

چه چیز دیگه‌ای باعث می‌شه یه تصمیم، معماری محسوب بشه؟ معمولاً تصمیم‌های معماری ساختار کلی معماری رو تحت تأثیر قرار می‌دن—مثلاً اینکه آیا از معماری یکپارچه (مونولیت) استفاده کنیم یا سراغ میکروسرویس‌ها بریم؟ اما گاهی وقت‌ها ممکنه تصمیم بگیریم یک ویژگی خاص معماری رو حفظ کنیم. برای مثال، اگر امنیت اولویت اصلی باشه، شرکت Two Many Sneakers ممکنه تصمیمی مثل این بگیره:

ما از صف‌ها (Queues) برای ارتباط غیرهم‌زمان (Asynchronous) بین سرویس‌ها استفاده خواهیم کرد. یادت باشه که تاپیک‌ها (Topics) مثل یه مکانیزم پخش (Broadcasting) هستن که هر سرویسی می‌تونه مشترک بشه و به پیام‌ها گوش بده. این تصمیم مربوط به ساختار نیست—بلکه به‌خاطر نیاز به امنیت گرفته شده. چون برای هر مشترک یه صف جداگانه داریم، دقیقاً می‌دونیم مصرف‌کننده‌ها چه کسانی هستن.

همه‌چیز در این فصل تا این لحظه به این نقطه‌ی مهم منتهی شده—گرفتن یک تصمیم معماری. ابتدا با تحلیل مصالحه‌ها شروع می‌کنی. بعد مزایا و معایب هر گزینه رو با توجه به محدودیت‌های دیگه بررسی می‌کنی، مثل نیازهای کسب‌وکار و کاربران نهایی، ویژگی‌های معماری، امکان‌پذیری فنی، محدودیت‌های زمانی و بودجه‌ای، و حتی دغدغه‌های توسعه. و در نهایت، می‌تونی تصمیم‌ات رو بگیری.

وایت‌بردها عالی‌ان، ولی باید یه روش دائمی‌تر برای ثبت تحلیل مصالحه‌ها (مزایا/معایب)، تصمیم نهایی، و از همه مهم‌تر، دلیل انتخاب اون تصمیم وجود داشته باشه. وایت‌بردها خیلی موقتی به‌نظر می‌رسن، نه؟

ثبت تصمیم‌ها به‌صورت دائمی اهمیت زیادی داره. تحلیل مصالحه‌ها هم یه فرآیند پیچیده‌ست، و واقعاً حیفه اگه همه‌ی اون تلاش‌ها با پاک کردن وایت‌برد از بین بره.

اما یه نکته‌ی کلیدی دیگه هم هست: خودِ تصمیم مهمه، ولی اینکه چرا اون تصمیم گرفته شده، شاید حتی مهم‌تر باشه. و این ما رو می‌رسونه به:

قانون دوم معماری نرم‌ افزار

گرفتن تصمیم، یکی از مهم‌ترین کارهایی‌ست که معماران نرم‌ افزار انجام می‌دن. فرض کن تو و تیمت تحلیل مصالحه‌ها رو انجام دادین و به این نتیجه رسیدین که برای بهبود عملکرد اپلیکیشن، از کش استفاده کنین. نتیجه‌ی این تحلیل اینه که یه جایی توی سیستم از کش استفاده می‌شه—و این «چی» به‌راحتی قابل تشخیصه.

اما اون تصمیم فقط بخشی از ماجراست. شرایطی که تصمیم توش گرفته شده، تأثیرش روی تیم اجرایی، و اینکه چرا از بین همه‌ی گزینه‌ها، اون یکی انتخاب شده—همه‌ی اینا هم به همون اندازه مهمن.

قانون دوم معماری نرم‌ افزار: «چرایی» مهم‌تر از «چگونگی» است

ببین، معماران آینده (یا حتی «خودِ آینده‌ی تو») شاید بتونن تشخیص بدن چه کاری انجام دادی و حتی چطور انجامش دادی—اما اینکه چرا اون کار رو به اون شکل انجام دادی، خیلی سخت قابل فهمه. اگه دلیل تصمیم‌ات مشخص نباشه، ممکنه وقتشون رو صرف بررسی راه‌حل‌هایی کنن که تو قبلاً به‌دلایل منطقی ردشون کردی، یا یه عامل کلیدی که تصمیم‌ات رو تحت تأثیر قرار داده، از دست بدن.

برای همین قانون دوم رو داریم. باید دلیل هر تصمیم رو بفهمی و ثبتش کنی تا در گذر زمان گم نشه.

حالا چطور تصمیم‌های معماری رو ثبت کنیم؟ در بخش بعدی بهش می‌پردازیم.

سوابق تصمیم‌گیری معماری (Architectural Decision Record – ADR)

یادت میاد هفته‌ی پیش دقیقاً چی کار کردی؟ نه؟ ما هم همین‌طور.
برای همین مستندسازی—به‌خصوص چیزهای مهم—خیلی اهمیت داره.

با توجه به قانون دوم معماری نرم‌ افزار، می‌دونیم که باید راهی داشته باشیم تا نه‌تنها خودِ تصمیم، بلکه دلیل گرفتن اون تصمیم رو هم ثبت کنیم.
معماران نرم‌ افزار از سوابق تصمیم‌گیری معماری (Architectural Decision Records – ADRs) استفاده می‌کنن تا این تصمیم‌ها رو ثبت کنن، چون یه قالب مشخص برای این کار در اختیارشون قرار می‌ده.

یک ADR (سوابق تصمیم‌گیری معماری) سندی‌ست که یک تصمیم معماری مشخص را توصیف می‌کند.
برای هر تصمیم معماری که می‌گیری، یکی از این اسناد را می‌نویسی.
با گذشت زمان، این اسناد تبدیل به یک لاگ یا سابقه‌ی تصمیم‌های معماری می‌شوند.
یادت باشد که تصمیم‌های معماری، بُعد دوم توصیف معماری‌ات را تشکیل می‌دهند—و ADRها همان مستنداتی هستند که از این بُعد پشتیبانی می‌کنند.

هر ADR در واقع سندی هست که یک تصمیم معماری مشخص رو توضیح می‌ده.
برای هر تصمیم معماری که می‌گیری، یه دونه از این سندها می‌نویسی.
با گذشت زمان، این اسناد جمع می‌شن و تبدیل می‌شن به یه لاگ کامل از تصمیم‌های معماری‌ات.

تو فصل اول در مورد ابعاد مختلف معماری نرم افزار توضیح دادیم. ADRها مستنداتی هستن که بـُـعد دوم (تصمیمات معماری) رو پشتیبانی میکنن.

یه ADR معمولاً هفت بخش داره:
عنوان، وضعیت، زمینه‌ (Context)، تصمیم، پیامدها، حاکمیت(تضمین پایبندی به تصمیم‌ها)، و در نهایت یادداشت‌ها.

هر چیزی که مربوط به یه تصمیم معماری باشه—از خودِ تصمیم گرفته تا دلایل و تأثیراتش—توی یکی از این بخش‌ها ثبت می‌شه.

۱- عنوان:

فرض کن یه تیم داره یه سرویس طراحی می‌کنه که نظرسنجی‌ها رو به مشتری‌ها ارائه می‌ده.
اونا تحلیل مصالحه‌ها رو انجام دادن و تصمیم گرفتن برای ذخیره‌ی نتایج نظرسنجی‌ها از یه دیتابیس رابطه‌ای استفاده کنن.

عنوان ADRشون ممکنه چیزی شبیه این باشه:
۰۴۲: استفاده از دیتابیس رابطه‌ای برای سرویس نظرسنجی مشتری‌ها

عنوان ADR بهتره بیشتر از اسم‌ها تشکیل شده باشه، نه فعل‌ها یا جمله‌های طولانی.
ساده و خلاصه بنویس—بعداً کلی فرصت داری که وارد جزئیات بشی.
عنوان باید دقیقاً بگه این سند درباره‌ی چیه، مثل تیتر یه مقاله یا پست وبلاگی.
اگه این بخش رو درست بنویسی، بقیه‌ی سند راحت‌تر جلو می‌ره.

عنوان باید با یه عدد شروع بشه—پیشنهاد می‌شه از عددهای سه‌رقمی استفاده کنی، با صفرهای اولش اگه لازم شد.
مثلاً از ۰۰۱ شروع کن برای اولین ADR، و همین‌طور ادامه بده تا ۹۹۹.
هر بار که یه ADR جدید اضافه می‌کنی، عددش رو یکی زیاد کن.
اینطوری هر کسی که داره سوابق رو می‌خونه، راحت می‌فهمه کدوم تصمیم‌ها زودتر گرفته شدن و ترتیبشون چی بوده.

۲- وضعیت:

عالیه! حالا که یه عنوان خوب و واضح انتخاب کردی، نوبت اینه که وضعیت اون تصمیم رو مشخص کنی. وضعیت نشون می‌ده تیم الان دقیقاً کجای فرآیند تصمیم‌گیری قرار داره.

ولی یه لحظه—مگه هدف ADR ثبت یه تصمیم نیست؟ خب، یه جورایی آره.
اما گرفتن تصمیم خودش یه فرآینده، نه یه لحظه‌ی خاص.

سند ADRها فقط تصمیم‌های معماری رو ثبت نمی‌کنن، بلکه نقش مستندات رو هم دارن—یه راه برای اشتراک‌گذاری و همکاری راحت‌تر. ممکنه بقیه‌ی اعضای تیم بخوان اون رو بررسی کنن یا حتی تأییدش کنن.

بیاین با هم نگاهی بندازیم به انواع وضعیت‌هایی که یه ADR می‌تونه داشته باشه.

درخواست نظر (Request For Comment – RFC)

از این وضعیت برای ADRهایی استفاده می‌شه که هنوز نیاز به نظر و بازخورد دارن—مثلاً از تیم‌های دیگه یا یه گروه مشاوره.
معمولاً این نوع تصمیم‌ها روی چند تیم تأثیر می‌ذارن یا مربوط به مسائل کلی مثل امنیت هستن.

وقتی یه ADR تو وضعیت RFC باشه، یعنی هنوز پیش‌نویسه و برای نظر دادن و نقد بازه—هر کسی که دعوت شده می‌تونه نظر بده.
فقط یادت باشه که یه «مهلت پاسخ‌گویی» براش مشخص کنی تا همه بدونن تا کی فرصت دارن نظر بدن.

پیشنهادی (Proposed)

وقتی همه نظر دادن (یا مهلت نظر دادن تموم شد)، وضعیت ADR می‌ره روی «پیشنهادی».
یعنی تصمیم هنوز نهایی نشده و منتظر تأییدهاست.
ممکنه تو این مرحله تصمیم رو ویرایش کنی یا حتی کامل عوضش کنی، مخصوصاً اگه یه محدودیت جدید پیدا کنی که کل قضیه رو منتفی کنه.

به‌عبارتی، هنوز تصمیم قطعی نگرفتی—ولی داری بهش نزدیک می‌شی.

پذیرفته‌شده (Accepted)

همون‌طور که از اسمش پیداست، یعنی تصمیم گرفته شده و همه‌ی افراد لازم باهاش موافقن.
وقتی یه ADR به وضعیت Accepted می‌رسه، یعنی تیم اجرایی می‌تونه دست‌به‌کار بشه و تصمیم رو پیاده‌سازی کنه.
دیگه وقت بحث و بررسی گذشته—الان وقت عمله.

اگه نیازی به نظر یا تأیید از بقیه نیست، می‌تونی وضعیت ADR رو همون اول بذاری روی «پذیرفته‌شده» (Accepted) به‌محض اینکه تصمیم گرفته شد.

بیشتر ADRها تو همین وضعیت (Accepted) می‌مونن، ولی یه وضعیت دیگه هم هست که باید حواست بهش باشه:

جایگزین‌شده (Superseded)

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

حالا چی کار باید کرد؟
یه ADR جدید می‌نویسی. اون تصمیم قبلی با تصمیم جدید جایگزین می‌شه، و این موضوع رو توی سند ثبت می‌کنی. مثلاً تیم نظرسنجی مشتری‌ها می‌فهمه که دیتابیس رابطه‌ای دیگه جواب نیازهاشون رو نمی‌ده، یه تحلیل جدید انجام می‌دن و تصمیم می‌گیرن از یه دیتابیس سندی (Document Store) استفاده کنن.

عنوان و وضعیت ADRهای قبلی و جدید ممکنه این شکلی باشه:

۰۴۲: استفاده از دیتابیس رابطه‌ای برای سرویس نظرسنجی مشتری‌ها وضعیت: پذیرفته‌شده (Accepted)، با ADR شماره ۰۶۸ جایگزین شده (Superseded by 068)

۰۶۸: استفاده از Document Store برای سرویس نظرسنجی مشتری‌ها وضعیت: پذیرفته‌شده (Accepted)، جایگزین ADR شماره ۰۴۲ شده. (Supersedes 042)

خیلی مهمه که هر دو ADR به‌وضوح مشخص کنن کدوم یکی جایگزین شده و کدوم یکی جایگزین‌کننده‌ست.
این لینک دوطرفه باعث می‌شه هر کسی که داره یه ADR قدیمی رو می‌خونه، سریع بفهمه دیگه معتبر نیست و دقیقاً بدونه باید بره سراغ کدوم سند جدید برای جزئیات تصمیم تازه.

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

۳- زمینه(Context):

زمینه خیلی مهمه. هر تصمیمی که تا حالا گرفتی، تو یه شرایط خاص و با یه سری محدودیت‌ها بوده. مثلا همین صبح که تصمیم گرفتی چی بخوری، احتمالا به این فکر کردی که چقدر گرسنه‌ای، بدنت چه حالی داره، برای ناهار چی قراره بخوری، یا اینکه داری تلاش می‌کنی فیبر بیشتری مصرف کنی. معماری نرم‌ افزار هم دقیقا همینطوره—تصمیماتش بدون در نظر گرفتن زمینه، معنی ندارن.

بخش «زمینه» توی قالب ADR همون جاییه که باید توضیح بدی چه شرایطی باعث شد اون تصمیم رو بگیری. هر چیزی که روی انتخابت تأثیر گذاشته—چه فنی، چه غیر فنی—باید اینجا بیاد. معمولاً دلایل تکنولوژیکی توی این لیست هستن، ولی اینکه عوامل فرهنگی یا حتی سیاسی رو هم اضافه کنی اصلاً عجیب نیست؛ چون کمک می‌کنه کسی که داره می‌خونه بهتر بفهمه از کجا اومدی و چرا اون تصمیم برات منطقی بوده.

مثال: باید نحوه‌ی ذخیره‌سازی پاسخ‌های نظرسنجی مشتری‌ها رو ساده‌تر کنیم. الان داده‌ها توی یه دیتابیس رابطه‌ای نگهداری می‌شن، ولی چون ساختارش خیلی خشک و سخت‌گیرانه‌ست، با تغییراتی که توی نظرسنجی‌ها داریم می‌دیم—مثلاً اضافه کردن نسخه‌های متفاوت یا پیشرفته‌تر برای مشتری‌های ویژه—داره دردسرساز می‌شه. چند تا گزینه داریم که می‌تونن کمک‌کننده باشن، مثل استفاده از نوع داده‌ی JSONB توی PostgreSQL یا اینکه کلاً بریم سراغ دیتابیس‌های سندمحور مثل MongoDB.

بخش «زمینه» توی ADR جواب این سؤال رو می‌ده که:
«اصلاً چرا مجبور شدیم این تصمیم رو بگیریم؟»

حواست باشه، اینجا هنوز قرار نیست خود تصمیم رو توضیح بدیم—برای اون یه بخش جدا داریم. این قسمت فقط قراره شرایط و دلایلی رو روشن کنه که ما رو به سمت اون تصمیم کشوندن.

۴- تصمیم:

خب، بالاخره رسیدیم به بخش اصلی—خودِ تصمیم.

اگه وضعیت ADR هنوز تو مرحله‌ی «پیشنهاد» یا «درخواست نظر» باشه، یعنی تصمیم نهایی گرفته نشده. با این حال، بخش «تصمیم» باید خیلی واضح بگه که قراره چه تصمیمی گرفته بشه. لحن نوشتار هم باید همینو نشون بده—بهتره با یه لحن قاطع و فعال بنویسی، مثلاً بگی «ما از فلان چیز استفاده خواهیم کرد» نه اینکه بگی «فکر می‌کنیم فلان چیز خوبه».

این بخش همچنین جاییه که باید توضیح بدی چرا داری این تصمیم رو می‌گیری. اینجاست که قانون دوم معماری نرم‌ افزار وارد می‌شه: «چرایی مهم‌تر از چگونگیه». چون آدم‌های آینده—چه خودت باشی، چه کسی که داره این سند رو می‌خونه—نباید فقط تصمیم رو بفهمن، بلکه دلیل پشتش رو هم باید متوجه بشن.

توی بخش «زمینه»، توضیح دادی که چرا اصلاً این تصمیم مطرح شده. بعدش، بخش «تصمیم» میاد که خودِ تصمیم رو روشن و واضح بیان می‌کنه. این دوتا کنار هم باعث می‌شن کسی که داره سند رو می‌خونه، بتونه تصمیم رو درست و کامل درک کنه—هم دلیلش رو بدونه، هم نتیجه‌اش رو.

نکته:

یادت باشه، توی ADR قرار نیست کسی نظر شخصی‌اش رو درباره‌ی وضعیت‌ها بنویسه. خیلی راحت می‌شه توی اون فاز افتاد، مخصوصاً وقتی داری تصمیمی رو توجیه می‌کنی. حتی موقع توضیح دادن زمینه هم ممکنه سخت باشه که بی‌طرف بمونی.

با ADR مثل یه خبرنگار حرفه‌ای برخورد کن—فقط حقایق رو بنویس و لحن‌ت رو خنثی نگه دار. هدف اینه که سندت قابل اعتماد و شفاف باشه، نه اینکه رنگ و بوی سلیقه‌ای بگیره.

۵- پیامدها

هر تصمیمی یه سری عواقب داره. مثلاً اگه دیروز حسابی ورزش کرده باشی، امروز ممکنه بدنت درد بگیره—ولی شاید یه کوچولو هم به خودت افتخار کنی!

مهمه که پیامدهای تصمیمات معماری—چه خوب، چه بد—رو بشناسیم و ثبتشون کنیم. این کار باعث می‌شه همه بدونن دقیقاً با اون تصمیم چه چیزهایی درگیر می‌شن، مخصوصاً تیم‌هایی که تحت تأثیر قرار می‌گیرن. از همه مهم‌تر، کمک می‌کنه بشه سبک‌سنگین کرد که آیا خوبی‌های اون تصمیم، بدی‌هاش رو پوشش می‌دن یا نه. این یعنی شفافیت واقعی توی فرآیند تصمیم‌گیری.

پیامدهای یه ADR می‌تونن خیلی محدود باشن یا برعکس، کلی اثر بذارن. تصمیمات معماری ممکنه روی چیزای مختلفی تأثیر بذارن—از تیم‌ها گرفته تا زیرساخت، بودجه، و حتی خودِ اجرای اون تصمیم. اینم یه لیست ناقص از سؤال‌هایی که باید از خودت بپرسی:

• این تصمیم چه تأثیری روی تیم اجرایی داره؟ مثلاً الگوریتم‌ها رو تغییر می‌ده؟ تست کردن رو سخت‌تر یا آسون‌تر می‌کنه؟ از کجا بفهمیم که «کارمون تموم شده»؟
• آیا این تصمیم باعث اضافه شدن یا حذف یه بخش از زیرساخت می‌شه؟ اگه آره، دقیقاً چه چیزایی رو درگیر می‌کنه؟
• موضوعات کلی مثل امنیت یا قابلیت مشاهده (observability) تحت تأثیر قرار می‌گیرن؟ اگه بله، این تغییرات چه اثری روی کل سازمان دارن؟
• این تصمیم چطور روی زمان و بودجه‌ات اثر می‌ذاره؟ هزینه‌زا هست یا صرفه‌جویی می‌کنه؟ اجرای اون سخت و زمان‌بره یا کار رو راحت‌تر می‌کنه؟
• آیا این تصمیم یه مسیر یک‌طرفه ایجاد می‌کنه؟ مثلاً وقتی از صف‌ها (queues) استفاده می‌کنی، دیگه نمی‌تونی ترتیب دقیق پیام‌ها رو کنترل کنی—یعنی یه جورایی داری اختیار یه بخش از سیستم رو واگذار می‌کنی.

همکاری با بقیه یه راه عالیه برای اینکه مطمئن بشی ارزیابی‌ات کامل و دقیق شده. هرچقدر هم خودت با دقت به پیامدهای یه تصمیم معماری فکر کنی، باز احتمال داره یه چیزایی از قلم بیفته. وقتی چند نفر با دیدگاه‌های مختلف وارد ماجرا می‌شن، احتمال اینکه نکات مهم‌تری کشف بشه خیلی بیشتره. اینطوری تصمیم‌گیری‌ات هم پخته‌تر می‌شه، هم قابل اتکاتر.

مثال پیامدها: چون قراره برای همه‌ی نظرسنجی‌ها از یه ساختار واحد استفاده کنیم، اگه یه سؤال مشترک بخواد تغییر کنه—چه اضافه بشه، چه حذف یا ویرایش—باید چندتا سند مختلف رو همزمان آپدیت کنیم. از طرفی، تیم IT باید موقع انتقال داده‌ها از دیتابیس رابطه‌ای به دیتابیس سندمحور، قابلیت نظرسنجی رو موقتاً غیرفعال کنه که این یعنی یه دوره‌ی قطعی و از دسترس خارج شدن سیستم.

۶- تضمین پایبندی به تصمیم

تا حالا شده یه تصمیم سال نو بگیری و تا آخر فروردین بی‌خیالش بشی؟ مثلاً بری عضویت باشگاه بگیری ولی آخرش فقط پول بدی و هیچ‌وقت نری تمرین؟. واقعیت اینه که یه تصمیم فقط وقتی ارزش داره که بهش عمل کنی—و مهم‌تر اینکه بعداً یادت نره و از مسیرش منحرف نشی.

خب، تو و تیمت کلی وقت گذاشتین، همه‌ی گزینه‌ها رو سبک‌سنگین کردین و یه ADR نوشتین تا تصمیم‌تون رو ثبت کنین. حالا چی؟ چطور مطمئن می‌شی که این تصمیم درست اجرا می‌شه—و مهم‌تر اینکه بعداً ازش منحرف نمی‌شین؟

اینجاست که بخش «نظارت» یا همون Governance وارد بازی می‌شه، که یکی از بخش‌های کلیدی هر ADR محسوب می‌شه. اینجا باید مشخص کنی چطور قراره مطمئن بشی سازمانت به این تصمیم پایبند می‌مونه—چه الان، چه در آینده. می‌تونی از روش‌های دستی مثل برنامه‌نویسی دونفره یا بازبینی کد استفاده کنی، یا بری سراغ ابزارهای خودکار مثل فریم‌ورک‌های تست تخصصی. هدف اینه که تصمیم فقط روی کاغذ نمونه، بلکه واقعاً توی عمل هم پیاده‌سازی بشه و موندگار بمونه.

۷- یادداشت‌های پایانی

بخش «یادداشت‌ها» یا همون Notes، اطلاعات متا درباره‌ی خودِ ADR رو شامل می‌شه—یعنی چیزهایی که به سند مربوط می‌شن، نه به تصمیم. معمولاً این فیلدها رو توی ADRها می‌ذاریم:

• نویسنده‌ی اصلی
• تاریخ تأیید
• تأییدکننده
• تاریخ جایگزینی (اگه این ADR با یه تصمیم جدید جایگزین شده باشه)
• تاریخ آخرین تغییر
• کسی که آخرین تغییر رو داده
• توضیح آخرین تغییر

این اطلاعات کمک می‌کنن بدونی کی چی نوشته، کی تأیید کرده، و سند در طول زمان چه تغییراتی کرده. یه جور شناسنامه‌ی فنی برای تصمیمه.

نکاتی در خصوص ADRها:

مدیریت و نگهداری ADRها:

برای ذخیره‌سازی و مدیریت ADRها، گزینه‌های زیادی وجود داره—همه‌چیز بستگی داره به اینکه تیم شما با چی راحت‌تره و چه کسانی قراره این سندها رو بخونن یا توش مشارکت کنن.

یکی از گزینه‌ها اینه که ADRها رو به صورت فایل‌های متنی ساده (مثل Markdown یا AsciiDoc) توی یه سیستم کنترل نسخه مثل Git نگهداری کنین. اینطوری تاریخچه‌ی تغییرات همیشه در دسترسه. البته یه ایرادش اینه که افراد غیرفنی ممکنه بلد نباشن چطور به این فایل‌ها دسترسی پیدا کنن. اگه این روش رو انتخاب کردین، بهتره ADRها رو توی یه ریپازیتوری جداگانه بذارین، نه وسط کدهای پروژه.

یه گزینه‌ی دیگه استفاده از ویکی‌هاست. بیشتر ویکی‌ها از ویرایشگر WYSIWYG استفاده می‌کنن، یعنی «هر چی می‌بینی همونه که می‌گیری»، و این باعث می‌شه افراد بیشتری بتونن راحت باهاش کار کنن. فقط مطمئن بشین که اون ویکی قابلیت پیگیری تغییرات رو داره، چون نمی‌خواین کسی یه ADR رو تصادفی تغییر بده بدون اینکه کسی خبردار بشه.

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

ابعاد ADRها:

تصمیمات معماری یا ADRها می‌تونن دامنه‌ی خیلی متفاوتی داشته باشن—از یه پروژه‌ی خاص گرفته تا کل سازمان.

• بعضی ADRها فقط روی یه تیم یا پروژه تأثیر می‌ذارن و خیلی محدودن.
• بعضی دیگه ممکنه چندین تیم یا پروژه رو درگیر کنن.
• و بعضی‌ها مثل «دستور API جف بزوس» توی آمازون، کل سازمان رو تحت تأثیر قرار می‌دن. اون تصمیم معروف می‌گفت که همه‌ی سرویس‌های آمازون فقط باید از طریق API با هم ارتباط برقرار کنن—یه تصمیم سازمانی بزرگ با اثرات گسترده.

درنتیجه ADRهایی که چند تیم یا پروژه رو درگیر می‌کنن معمولاً نیاز به همکاری زیاد دارن و اغلب باید توسط یه نهاد مرکزی مثل هیئت بررسی معماری تأیید بشن. این نوع تصمیم‌ها معمولاً به موضوعات سراسری مثل نحوه‌ی ارتباط سرویس‌ها، پروتکل‌های انتقال داده، امنیت یا رعایت مقررات مربوط می‌شن.

فرآیند نوشتن ADR رو تا حد ممکن بدون ساده نگه دار

خیلی وسوسه‌انگیزه که بخوای بخش‌های بیشتری به قالب ADR اضافه کنی تا همه‌چیز رو پوشش بدی. هدف خوبیه، ولی نتیجه‌اش اینه که کار بیشتر می‌شه. اگه هی به این «هیولا» غذا بدی، مستندسازی تبدیل می‌شه به یه کار سخت و وقت‌گیر—و ممکنه باعث بشه بعضی‌ها کلاً بی‌خیال نوشتن ADR بشن.

پس تمرکزت رو بذار روی خلاصه‌نویسی و سادگی. ساده نگهش دار. بعداً از خودت تشکر می‌کنی!

نکات کلیدی:

• معماری یه چیز ثابت نیست؛ همیشه در حال تغییر و رشد کردنه.
• وقتی نیازها یا شرایط عوض می‌شن، باید معماری رو هم باهاش هماهنگ کنی.
• برای هر تصمیم، چندتا گزینه داری. برای انتخاب بهترین (یا کم‌بدترین)، باید مزایا و معایب هر گزینه رو با هم بررسی کنی. این یه تمرین تیمیه که کمک می‌کنه همه‌ی جوانب رو ببینی.
• قانون اول معماری نرم افزار: همه‌چیز توی معماری یه معامله‌ست.
• جواب همه‌ی سؤال‌ها توی معماری اینه: «بستگی داره». برای اینکه بفهمی کدوم راه‌حل به درد موقعیتت می‌خوره، باید بدونی اولویت‌ها و هدف‌ها چیه. نیازها چطورن؟ چی برای مشتری و ذی‌نفع مهم‌تره؟ دنبال سرعتی رسیدن به بازار هستی یا پایداری در فاز رشد؟
• نتیجه‌ی تحلیل مزایا و معایب، یه تصمیم معماریه—یکی از چهار بُعد اصلی برای توصیف معماری.
• تصمیم معماری یعنی بررسی همه‌ی گزینه‌ها با توجه به محدودیت‌های مختلف مثل فرهنگ تیم، مسائل فنی، نیازهای تجاری و خواسته‌های مشتری، و انتخاب چیزی که با این شرایط بیشترین هم‌خوانی رو داره.
• تصمیم‌گیری فقط انتخاب یه گزینه نیست؛ مهم‌تر از اون اینه که بدونی چرا اون گزینه رو انتخاب کردی.
• قانون دوم معماری نرم‌ افزار: «چرایی» مهم‌تر از «چگونگی» است.
• برای اینکه ثبت تصمیمات معماری یه روال مشخص و رسمی داشته باشه، از سندهایی به اسم ADR استفاده کن. این سندها ۷ بخش دارن: عنوان، وضعیت، زمینه، تصمیم، پیامدها، نظارت، و یادداشت‌ها.
• با گذشت زمان، مجموعه‌ی ADRهات تبدیل می‌شن به حافظه‌ی معماری پروژه‌ت.
• عنوان هر ADR باید با یه عدد سه‌رقمی شروع بشه و بعدش یه توضیح خلاصه و دقیق از تصمیم موردنظر بیاد—ترجیحاً با تمرکز روی اسم‌ها، نه فعل‌ها.
• یه ADR می‌تونه وضعیت‌های مختلفی داشته باشه، بسته به نوعش و جایی که توی جریان تصمیم‌گیری قرار گرفته.
• وقتی همه‌ی افراد مسئول تصمیم، اون رو تأیید کنن، وضعیتش می‌شه «پذیرفته‌شده» (Accepted).
• اگه یه تصمیم جدید جای اون تصمیم قبلی رو بگیره، باید یه ADR جدید بنویسی. اون قبلی می‌ره تو حالت «جایگزین‌شده» (Superseded) و جدید می‌شه «پذیرفته‌شده».
• قسمت زمینه (Context) توضیح می‌ده چرا اصلاً لازم بود این تصمیم گرفته بشه.
• قسمت تصمیم (Decision) خود تصمیم رو ثبت می‌کنه و دلیل انتخاب اون گزینه رو هم می‌گه.
• قسمت پیامدها (Consequences) اثرات مثبت و منفی تصمیم رو مشخص می‌کنه تا مطمئن بشیم خوبی‌هاش می‌چربه به بدی‌ها، و تیم اجرایی بهتر بتونه باهاش کنار بیاد.
• قسمت نظارت (Governance) راه‌هایی رو معرفی می‌کنه که کمک می‌کنن تصمیم درست اجرا بشه و بعداً از مسیرش منحرف نشیم.
• آخرین بخش ADR، یعنی Notes، بیشتر اطلاعاتی درباره‌ی خود سند رو ثبت می‌کنه—مثل اینکه کی نوشته، کی تأیید شده، و آخرین بار کی ویرایش شده.
• تصمیمات معماری یا ADRها ابزار مهمی‌ان برای پایبندی به قانون دوم معماری نرم‌ افزار، چون فقط نمی‌گن «چه» تصمیمی گرفته شده، بلکه «چرا»ش رو هم ثبت می‌کنن.
• اسناد ADR برای ساختن دانش سازمانی و کمک به یادگیری تیم‌ها از همدیگه ضروری‌ان.