آیا AI می‌تواند معماری یک نرم‌افزار را طراحی کند؟

سؤال رایج تیم‌ها این است: اگر مدل می‌تواند دیاگرام بکشد، الگو پیشنهاد دهد و حتی ADR بنویسد، هنوز به معمار نرم‌افزار (Software Architect) نیاز داریم؟ واقعیت عملی ساده‌تر و سخت‌تر از شعارهاست. AI در articulation الگوها و فهرست کردن trade-offها قوی است؛ در فهم قیود نانوشتهٔ سازمان، ظرفیت عملیات، و مسئولیت پیامدها ضعیف می‌ماند.

معماری تصمیم‌هایی است که تغییرشان گران است: مرز سرویس، مدل داده، قرارداد API، استراتژی استقرار، و سطح پذیرش ریسک. این تصمیم‌ها فقط دانش الگوی کتاب نیستند؛ به اندازهٔ تیم، بلوغ مشاهده‌پذیری، بودجهٔ حادثه، و نقشهٔ محصول وابسته‌اند. مدلی که آن‌ها را ندیده، معماری «درست روی کاغذ و اشتباه در زمینه» می‌سازد.

پاسخ کوتاه

بله، AI می‌تواند پیش‌نویس معماری، گزینه‌های الگو، و نقد فرض‌ها را تولید کند. نه، AI نمی‌تواند به‌تنهایی معماری قابل اتکا برای سیستم واقعی طراحی و مالک شود. نقش معمار باقی می‌ماند: قیود را استخراج کند، گزینه را انتخاب کند، تصمیم را مستند کند، و پیامد Production را بپذیرد. بهترین استفاده، همکاری Design-First است نه «یک پرامپت، یک معماری نهایی».

معماری بدون مالکیت ریسک فقط اسلاید است؛ AI اسلاید می‌سازد، معمار مسئول می‌ماند.

معماری دقیقاً چه کاری است؟

معماری انتخاب ساختار برای برآوردن کیفیت‌های غیرعملکردی است: مقیاس‌پذیری، قابلیت تغییر، امنیت، مشاهده‌پذیری، هزینهٔ عملیات، و زمان رسیدن به بازار. Fowler و منابع معماری کلاسیک تأکید دارند مرزها و قراردادها مهم‌تر از نام الگو هستند. اگر مونولیت ماژولار نیاز را برآورده کند، پیشنهاد میکروسرویس فقط به‌خاطر مد، بدهی است.

• تعریف مرز دامنه و جریان داده
• انتخاب سبک استقرار و جداسازی شکست
• تعیین قرارداد بین اجزا و نسخه‌بندی
• ثبت تصمیم با ADR و معیار بازنگری
• هم‌راستایی با ظرفیت تیم و عملیات

AI در طراحی معماری کجا قوی است؟

فهرست گزینه‌ها و trade-off

مدل می‌تواند برای یک مسئله چند گزینه بیاورد: مونولیت ماژولار، سرویس‌های مرزی، صف رویداد، یا CQRS. اگر قیود را صریح بدهید (دو مهندس، یک کلاستر، بدون service mesh)، خروجی از حالت کلیشه‌ای فاصله می‌گیرد. این نقش sparring partner است نه تصمیم‌گیرنده.

آشکارسازی فرض‌های پنهان

با پرسش‌های ساخت‌یافته می‌توانید مدل را وادار کنید فرض‌ها، حالت‌های شکست، و وابستگی‌های عملیات را لیست کند. این کار شبیه whiteboard با همکار است: شما هدایت می‌کنید، مدل حافظهٔ الگو را باز می‌کند.

پیش‌نویس ADR و دیاگرام

نوشتن Architecture Decision Record و شرح گزینهٔ ردشده زمان‌بر است. AI پیش‌نویس می‌دهد؛ معمار صحت، زمینهٔ سازمانی، و معیار بازنگری را اصلاح می‌کند. بدون این لایه، ADR تبدیل به متن تولیدشدهٔ بی‌مالک می‌شود.

AI کجا شکست می‌خورد؟

شکست رایج، معماری از نظر فنی منسجم و از نظر زمینه غلط است. مدل با لحنی مطمئن می‌نویسد؛ همان لحن برای دانش عمیق و حدس خالی یکسان است. Stack Overflow Developer Survey 2025 نشان می‌دهد توسعه‌دهندگان برای کارهای سیستمی با مسئولیت بالا مثل planning و deployment مقاومت بیشتری دارند؛ معماری دقیقاً در همین دسته است.

• نادیده گرفتن اندازهٔ تیم و on-call
• پیشنهاد الگوی سنگین بدون Premium پیچیدگی
• فرض زیرساخت و مهارت‌هایی که وجود ندارد
• مهاجرت چندساله را مثل تغییر یک‌هفته‌ای توصیف کردن
• امنیت و انطباق را به «بعداً اضافه کنید» موکول کردن

NIST AI RMF روی نظارت انسانی و سنجش ریسک تأکید دارد: خروجی مدل را بدون GOVERN و MEASURE وارد تصمیم گران نکنید.

چارچوب Design-First با AI

Martin Fowler در Design-First Collaboration پیشنهاد می‌کند قبل از کد، سطوح طراحی را مرحله‌به‌مرحله پیش ببرید: قابلیت‌ها، اجزا، تعاملات، قراردادها، و فقط در پایان پیاده‌سازی. هر سطح نقطهٔ تأیید انسانی است. این دقیقاً ضد «کل سیستم را معماری کن و کد بده» است.

1. Capabilities: مسئله و محدوده را هم‌معنا کنید.
2. Components: مرزها را با نام‌گذاری پروژه مشخص کنید.
3. Interactions: جریان داده و شکست جزئی را بکشید.
4. Contracts: API، رویداد، و سازگاری نسخه را قفل کنید.
5. Implementation: فقط پس از تأیید، پیش‌نویس کد بخواهید.

Knowledge Priming مکمل این روش است: قبل از جلسه، stack با نسخه، قرارداد نام‌گذاری، و ADRهای موجود را به مدل بدهید. بدون priming، مدل به میانگین اینترنت برمی‌گردد نه به سیستم شما.

جدول نقش معمار و AI

مثال کوتاه: سفارش آنلاین

فرض کنید تیم هشت‌نفره می‌خواهد سفارش، موجودی و پرداخت را جدا کند. مدل ممکن است فوراً سه میکروسرویس، event bus و saga پیشنهاد دهد. معمار با قیود واقعی می‌پرسد: آیا تیم عملیات توزیع‌شده دارد؟ آیا موجودی و سفارش هنوز مرز پایدار دارند؟ آیا مشاهده‌پذیری end-to-end آماده است؟

پاسخ محتمل درست‌تر: مونولیت ماژولار با ماژول‌های دامنهٔ جدا، صف برای کارهای ناهمگام محدود، و استخراج سرویس فقط وقتی درد استقرار یا مقیاس واقعاً اندازه گرفته شد. AI این گزینه را هم می‌تواند بنویسد — اگر شما قیود و Monolith First را وارد گفتگو کنید.

اشتباه‌های رایج

• پذیرش معماری فقط چون دیاگرام زیبا و متن روان است.
• کپی معماری شرکت‌های hyperscale برای محصول ده‌هزار کاربر.
• حذف Review معماری چون «Agent تصمیم را توضیح داد».
• نداشتن ADR و تکیه به تاریخچهٔ چت مدل.
• تغییر مرز دامنه هر هفته بر اساس پیشنهاد جلسهٔ جدید AI.

چه وقت از AI برای معماری استفاده کنیم؟

مفید است وقتی مسئله را بلدید و می‌خواهید گزینه‌ها و اعتراض‌ها را سریع‌تر ببینید؛ وقتی ADR را پیش‌نویس می‌کنید؛ وقتی می‌خواهید فرض‌های طراحی را stress-test کنید. کم‌فایده یا خطرناک است وقتی دامنه هنوز کشف نشده، قیود سازمانی ثبت نشده، یا فشار موعد شما را به Accept بی‌Review می‌کشاند.

قانون عملی: هر تصمیم معماری تولیدشده با AI باید در جلسهٔ کوتاه انسانی با معیار «چه چیزی بعداً تغییرش را گران می‌کند؟» تأیید شود.

قیود سازمانی که مدل نمی‌بیند مگر بگویید

بیشتر شکست‌های معماری AI-assisted از کمبود دانش الگوی مدل نیست؛ از قیود ناگفته است. قبل از هر جلسهٔ معماری این‌ها را صریح بنویسید و در priming بگذارید:

• اندازه و مهارت تیم نگهداری و on-call
• سقف ابزارها و محدودیت‌های امنیتی/انطباق
• فرکانس استقرار و تحمل downtime
• بودجهٔ مشاهده‌پذیری و پیچیدگی عملیات
• افق زمانی محصول (کشف دامنه در برابر مقیاس پایدار)

بدون این لیست، مدل به سمت معماری‌های کنفرانسی می‌رود: service mesh، چند منطقه، و جداسازی زودهنگام. با این لیست، همان مدل گزینهٔ ساده‌تر و عملی‌تر پیشنهاد می‌کند.

معیار پذیرش برای پیشنهاد معماری AI

پیشنهاد معماری را مثل PR ارزیابی کنید. حداقل معیار:

1. قیود ورودی در سند آمده و با واقعیت تیم یکی است.
2. حداقل دو گزینه با trade-off نوشته شده، نه یک نسخهٔ واحد.
3. حالت‌های شکست و نقطهٔ تمرکز ریسک مشخص است.
4. مسیر مهاجرت/تدریجی بودن تغییر روشن است.
5. معیار بازنگری تصمیم (چه سیگنالی ADR را باطل می‌کند) وجود دارد.

اگر معیار پنجم نباشد، شش ماه بعد کسی نمی‌داند چرا این مرز انتخاب شد و مدل جلسهٔ بعد نسخهٔ متضاد می‌دهد.

هم‌زیستی معمار، Tech Lead و AI

در تیم‌های متوسط، معمار تمام‌وقت همیشه وجود ندارد. Tech Lead می‌تواند با AI سرعت articulation بگیرد، اما باید مرز تصمیم‌های برگشت‌ناپذیر را بداند. پیشنهاد عملی: تصمیم‌های محلی ماژول با Lead + AI؛ تصمیم‌های بین‌دامنه‌ای و دادهٔ مشترک با Review معماری یا شورای فنی کوتاه.

AI نباید جایگزین گفتگوی تیمی شود. خروجی مدل را در جلسهٔ ۱۵ دقیقه‌ای روی دیوار بگذارید و بپرسید «کدام فرض اینجا غلط است؟». این کار توهم اطمینان را می‌شکند.

امنیت و انطباق در معماری پیشنهادی مدل

مدل اغلب احراز هویت، رمزنگاری در حال انتقال، جداسازی Secret، و ممیزی را در حاشیه می‌گذارد یا با یک جملهٔ کلی رد می‌شود. برای مسیرهای هویت، پرداخت، و دادهٔ شخصی، از مدل بخواهید threat model سبک بنویسد؛ سپس آن را با استاندارد تیم و OWASP/NIST خودتان تطبیق دهید. خروجی تهدید مدل نقطهٔ شروع است نه گواهی انطباق.

اگر سازمان ابزار خاصی را ممنوع کرده، آن را در priming بگویید. در غیر این صورت ممکن است معماری روی سرویسی بنا شود که InfoSec هرگز تأیید نمی‌کند.

از دیاگرام تا اجرا: فاصله‌ای که باید مدیریت شود

دیاگرام تمیز حس پیشرفت می‌دهد، اما ارزش معماری وقتی معلوم می‌شود که اولین برش قابل استقرار ساخته شود. بعد از تأیید سطح Contracts، یک spike یک یا دو روزه تعریف کنید: یک مسیر حیاتی end-to-end با لاگ و متریک. اگر spike خلاف فرض‌ها بود، ADR را زود اصلاح کنید — قبل از اینکه ده فیچر روی مرز غلط ساخته شود.

AI می‌تواند checklist spike و تست پذیرش اولیه را پیشنهاد دهد؛ شما اولویت و تعریف «کافی برای یادگیری» را تعیین می‌کنید.

چک‌لیست جلسهٔ ۶۰ دقیقه‌ای معماری با AI

1. ۱۰ دقیقه: نوشتن قیود و هدف کیفیت (بدون ابزار).
2. ۱۰ دقیقه: priming با ADR و stack.
3. ۱۵ دقیقه: سطوح Capabilities تا Components با توقف تأیید.
4. ۱۵ دقیقه: Interactions و Contracts؛ ثبت اختلاف‌نظرها.
5. ۱۰ دقیقه: تصمیم موقت، owner، و تاریخ بازنگری در ADR پیش‌نویس.

اگر جلسه بدون توقف تأیید پیش برود، دوباره به خروجی یک‌شات برمی‌گردید. توقف‌ها هزینه نیستند؛ بیمهٔ تصمیم‌اند.

خلاصه

AI می‌تواند در طراحی معماری دستیار قوی باشد: الگو، trade-off، نقد، و پیش‌نویس سند. نقش Architect حذف نمی‌شود؛ متمرکزتر می‌شود روی قیود، انتخاب، مالکیت ریسک، و هم‌راستایی با عملیات. اگر فقط یک عادت این ماه بسازید، Design-First را جایگزین «یک‌شات معماری کامل» کنید و هر تصمیم را با ADR امضا کنید.

سوالات متداول

آیا Junior با AI می‌تواند معماری Production بدهد؟

می‌تواند پیش‌نویس خوب بسازد، اما بدون تجربهٔ شکست‌های واقعی و فهم عملیات، احتمال معماری زمینه‌غلط بالاست. مسیر سالم: پیشنهاد AI + Review معمار/Lead.

آیا دیاگرام تولیدشده با AI کافی است؟

خیر. دیاگرام بدون قیود، معیار کیفیت، و برنامهٔ مهاجرت سند تصمیم نیست.

اگر مدل دو معماری متضاد پیشنهاد داد چه کنیم؟

این نشانهٔ سالم بودن sparring است. معیار انتخاب را از قیود تیم بنویسید، نه از اعتماد به لحن مدل.

منابع و مراجع

• Martin Fowler — Design-First Collaboration: https://martinfowler.com/articles/reduce-friction-ai/design-first-collaboration.html
• Martin Fowler — Patterns for Reducing Friction in AI-Assisted Development: https://martinfowler.com/articles/reduce-friction-ai/
• Martin Fowler — Monolith First: https://martinfowler.com/bliki/MonolithFirst.html
• NIST AI Risk Management Framework: https://www.nist.gov/itl/ai-risk-management-framework
• Stack Overflow Developer Survey 2025 — AI: https://survey.stackoverflow.co/2025/ai/