Software Architecture یا معماری نرم‌افزار مجموعه تصمیم‌های ساختاری است که مشخص می‌کند مسئولیت‌ها در چه اجزایی قرار بگیرند، اجزا چگونه با یکدیگر ارتباط داشته باشند و سیستم چگونه توسعه، تست و مستقر شود. معماری فقط نقشه کلاس‌ها نیست. دیتابیس، مرز سرویس‌ها، تحمل خطا، امنیت، استقرار و تجربه تیم توسعه نیز بخشی از آن هستند.
تفاوت معماری با دیزاین پترن و سیستم دیزاین
دیزاین پترن معمولاً راهکاری برای یک مسئله تکرارشونده در طراحی اجزای نرم‌افزار است. معماری درباره ساختار کلان و وابستگی‌های سیستم تصمیم می‌گیرد. سیستم دیزاین فرایند طراحی عملی سیستم با توجه به نیازمندی‌ها، ظرفیت، داده، زیرساخت و محدودیت‌هاست. این سه مفهوم هم‌پوشانی دارند، اما مترادف نیستند.
معروف‌ترین سبک‌های معماری نرم‌افزار
| سبک معماری | ایده اصلی | مزیت | محدودیت |
|---|---|---|---|
| Monolithic | یک برنامه یکپارچه و یک واحد استقرار | شروع سریع، دیباگ ساده‌تر | رشد کد و تغییرات تیمی در مقیاس بزرگ |
| Modular Monolith | یک استقرار با ماژول‌های مرزبندی‌شده | حفظ سادگی عملیات و جداسازی دامنه | نیاز به کنترل وابستگی میان ماژول‌ها |
| Layered / N-Tier | تفکیک لایه ارائه، منطق و داده | ساختار آشنا، مرز نقش‌ها | وابستگی‌های لایه‌ای و عبورهای زیاد |
| Clean Architecture | استقلال هسته کسب‌وکار از فریم‌ورک و دیتابیس | تست‌پذیری و تغییرپذیری | هزینه انتزاع و افزایش ساختار |
| Hexagonal / Ports & Adapters | پورت قراردادها را تعریف می‌کند و آداپتر به ابزارها متصل می‌شود | تست مستقل و تعویض اتصال‌ها | تعداد پورت و آداپتر زیاد |
| Microservices | سرویس‌های مستقل با مرز دامنه و استقرار جدا | مقیاس و استقرار جداگانه | خطاهای شبکه و سازگاری توزیع‌شده |
| Event-Driven | اجزا با انتشار و مصرف رویداد واکنش نشان می‌دهند | کاهش اتصال مستقیم بین خدمات | ردیابی جریان و تکرار پیام |
| SOA | سرویس‌های سازمانی با قراردادهای مشخص | اشتراک قابلیت‌ها بین سیستم‌ها | پیچیدگی حاکمیت و واسط‌ها |
| Microkernel / Plugin | هسته ثابت همراه افزونه‌های جدا | افزودن قابلیت بدون تغییر هسته | مدیریت نسخه و وابستگی افزونه‌ها |
| Serverless / FaaS | کد بر اساس رویداد با زیرساخت مدیریت‌شده اجرا می‌شود | پرداخت متناسب با مصرف | Cold Start، محدودیت اجرا و Vendor Lock-in |
| CQRS | مدل‌های خواندن و نوشتن را تفکیک می‌کند | بهینه‌سازی مستقل دو مسیر | همگام‌سازی و سازگاری نهایی |
| Pipe-and-Filter | داده از مراحل پردازش مستقل می‌گذرد | مناسب پردازش فایل و ETL | سربار انتقال و مدیریت خطا |
مثال معماری یک فروشگاه اینترنتی
برای فروشگاهی با یک تیم ۴ نفره و چند هزار سفارش روزانه، معمولاً یک مونولیت ماژولار با ماژول‌های سفارش، پرداخت و انبار می‌تواند شروع مناسبی باشد. هر ماژول مالک قوانین کسب‌وکار خودش است، ولی یک برنامه قابل استقرار داریم. وقتی نیازهای عملیاتی واقعاً مستقل شدند، می‌توان بعضی مرزها را به سرویس جدا تبدیل کرد. این تصمیم به تعداد سفارش به‌تنهایی وابسته نیست.
shop/
modules/
catalog/ # products and prices
orders/ # order lifecycle
payments/ # payment contracts and integration
inventory/ # stock reservations
shared/
observability/
authentication/
infrastructure/
database/
messaging/یک جریان رویدادمحور چه شکلی است؟
OrderService -> OrderPlaced event -> Message Broker
|-> Inventory reserves stock
|-> Notification sends receipt
|-> Analytics updates reportsاین جریان در استقرار واقعی به مدیریت خطا، تحویل حداقل یک‌باره پیام، آیدمپوتنسی و مشاهده‌پذیری نیاز دارد. اگر عملیات پرداخت و موجودی نیاز به هماهنگی طولانی داشته باشند، الگوی ساگا می‌تواند مطرح شود.
با چه معیارهایی معماری را انتخاب کنیم؟
| کیفیت مورد انتظار | سوال عملی |
|---|---|
| Performance | در زمان اوج خرید چه میزان تاخیر قابل قبول است؟ |
| Availability | قطع یک سرویس تا چه زمانی قابل تحمل است؟ |
| Scalability | کدام بخش باید مستقل مقیاس بگیرد؟ |
| Security | داده پرداخت و اطلاعات کاربران چگونه محافظت می‌شوند؟ |
| Maintainability | تغییر قانون تخفیف چه بخش‌هایی را درگیر می‌کند؟ |
| Deployability | چند بار در هفته نسخه منتشر می‌شود؟ |
| Observability | خرابی یک سفارش چگونه از ابتدا تا انتها ردیابی می‌شود؟ |
مقایسه انتخاب‌های معمول
در مونولیت، مرز تراکنش دیتابیس اغلب ساده‌تر است. در میکروسرویس، هر سرویس می‌تواند مستقل مقیاس بگیرد، ولی ارتباط شبکه، نسخه‌بندی API، مانیتورینگ و سازگاری داده هزینه دارند. Clean Architecture و Hexagonal لزوماً جایگزین این دو نیستند. می‌توان یک مونولیت یا یک میکروسرویس را هم با اصول کلین یا هگزاگونال طراحی کرد.
هیچ معماری بهترین گزینه برای همه پروژه‌ها نیست
ابتدا نیازمندی‌های فانکشنال و نان‌فانکشنال را مکتوب کنید. سپس معماری ساده‌ای را انتخاب کنید که محدودیت‌های واقعی سیستم را پوشش می‌دهد، نه پیچیده‌ترین اصطلاحات معماری را.
اصطلاحات فنی: سیستم دیزاین، نیازمندی فانکشنال، نیازمندی نان‌فانکشنال، معماری تمیز، معماری شش‌ضلعی، معماری مونولیتیک، میکروسرویس، معماری رویدادمحور.