معماری نرمافزار به ندرت درباره یافتن یک پاسخ «درست» واحد است. این مجموعهای از سازشهاست که تحت محدودیتهای خاص و با توجه به زمینه زمانی انجام میشود. با این حال، اغلب اوقات وقتی تیمی به فناوری پایگاه داده جدیدی مهاجرت میکند یا یک مونولیت را بازسازی مینماید، منطق پشت آن انتخاب در هوا محو میشود. ماهها بعد، توسعهدهندگان جدید به کد قدیمی نگاه میکنند و میپرسند: «چرا ما MongoDB را به جای PostgreSQL انتخاب کردیم؟»
اینجاست که رکوردهای تصمیم معماری (ADRs) وارد عمل میشوند. یک ADR سندی است که یک تصمیم مهم معماری را همراه با زمینه و پیامدهای آن ثبت میکند. این سند به عنوان تاریخچه تکامل نرمافزار شما عمل کرده و به نگهدارندگان آینده چرایی را ارائه میدهد، نه فقط چیستی را.
چرا ADRها مهم هستند
بدون مستندات، دانش معماری به دانش قبیلهای تبدیل میشود. این دانش در ذهن مهندسان ارشدی که ممکن است شرکت را ترک کنند، زنده است. ADRها این دانش را دموکراتیک میکنند. آنها به تیمها اجازه میدهند تا:
- تکامل طراحی را ردیابی کنند: درک کنند که سیستم در طول زمان چگونه تغییر کرده است.
- خستگی تصمیمگیری را کاهش دهند: به تصمیمات گذشته ارجاع دهند تا از بحث مجدد درباره مسائل حلشده جلوگیری کنند.
- فرآیند آنبوردینگ را بهبود بخشند: اعضای جدید تیم بتوانند سریعاً بدهی فنی و زمینه تاریخی را درک کنند.
- بررسیهای بهتر را تسهیل کنند: همکاران بتوانند تصمیمات را بر اساس زمینه به جای ترجیحات شخصی به چالش بکشند.
فرمت استاندارد ADR
اگرچه فرمتها میتوانند متفاوت باشند، رویکردی که توسط مایکل نایگارد و ADR.org محبوب شد، ساختاری مستحکم ارائه میدهد. یک ADR خوب باید شامل موارد زیر باشد:
- عنوان: یک شناسه منحصربهفرد و مختصر (مثلاً 001-use-postgres).
- وضعیت: پیشنهادی، پذیرفتهشده، منسوخشده یا جایگزینشده.
- زمینه: نیروهای محرک موجود، شامل محدودیتهای فنی، سازمانی یا مقرراتی.
- تصمیم: تغییر یا انتخاب واقعی انجامشده.
- پیامدها: مبادلات حاصل، هم مثبت و هم منفی.
پیادهسازی عملی
بهترین مکان برای ذخیره ADRها، در کنار کد منبع شماست، معمولاً در دایرکتوریای به نام docs/adr. این اطمینان حاصل میکند که مستندات همراه با کد، کنترل نسخه میشوند و از کسری مستندات جلوگیری میکنند.
در اینجا یک الگو برای ایجاد یک ADR با استفاده از Markdown آورده شده است:
## 002-adopt-event-sourcing
**Status**: Accepted
**Date**: 2023-10-27
### Context
Our current CRUD-based architecture struggles with audit requirements and data consistency across microservices. We need a way to track every change to a business entity's state for compliance and real-time analytics.
### Decision
We will adopt Event Sourcing for the Order Management service. Instead of storing the current state of an order, we will store a series of events (e.g., `OrderCreated`, `ItemAdded`, `OrderShipped`).
### Consequences
* **Positive**: Complete audit trail; easier to implement CQRS; supports replaying events for debugging.
* **Negative**: Increased complexity in handling state reconstruction; eventual consistency in read models; learning curve for the team.بهترین شیوهها برای پذیرش
برای موثر بودن ADRها، این راهنماها را دنبال کنید:
- آنها را سبک نگه دارید: یک ADR باید یک خلاصه باشد، نه یک رساله. اگر دیدید که بیش از یک صفحه مینویسید، به مستندات فنی دقیقتر لینک دهید.
- آنها را به صورت پیشدستانه ایجاد کنید: درباره ADR در جلسه طراحی خود بحث کنید، سپس آن را پیشنویس کنید. آن را برای بعد از واقعیت رها نکنید.
- آنها را بررسی کنید: با ADRها مانند کد رفتار کنید. درخواستهای کششی (Pull Requests) که آنها را اصلاح میکنند، بررسی کنید.
- آنها را به هم لینک دهید: اگر یک ADR جدید یکی از قدیمیها را جایگزین میکند، به وضوح دو مورد را به هم لینک دهید تا توالی آنها آشکار باشد.
نتیجهگیری
پیادهسازی ADRها یک شیوه کمهزینه و پربازده است. این کار معماری نرمافزار را از یک جعبه سیاه به یک رشته شفاف و قابل یادگیری تبدیل میکند. با ثبت زمینه و منطق تصمیمات خود، شما یک پایگاه دانش مقاوم میسازید که به تیم شما قدرت میدهد تا امروز تصمیمات بهتری بگیرد و سیستم خود را فردا درک کند. کوچک شروع کنید: یک تصمیم بزرگ اخیر را انتخاب کنید و امروز برای آن یک ADR بنویسید.