روش‌های نوین تحلیل سیستم‌های نرم‌افزاری بزرگ؛ از کشف دامنه تا معماری تکاملی

تحلیل سیستم‌های بزرگ چه تفاوتی با پروژه‌های کوچک دارد؟

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

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

چالش‌های اصلی تحلیل سیستم‌های نرم‌افزاری بزرگ

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

چارچوب چندلایه تحلیل سیستم‌های بزرگ

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

۱ کشف فرایندها با Event Storming

Event Storming چیست؟

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

نقطه شروع Event Storming فرم‌ها، جداول و ساختار فعلی نرم‌افزار نیست. نقطه شروع، رویدادهایی است که در کسب‌وکار رخ داده‌اند؛ مانند «درخواست ثبت شد»، «پرداخت تأیید شد»، «ظرفیت تکمیل شد» یا «نوبت لغو شد».

اجزای اصلی Event Storming

• Domain Event: اتفاق مهمی که رخ داده است.
• Command: دستوری که باعث وقوع رویداد شده است.
• Actor: فرد یا سیستمی که فرمان را صادر می‌کند.
• Policy: قانونی که پس از یک رویداد، فرمان دیگری را فعال می‌کند.
• Aggregate: بخشی از مدل دامنه که از قوانین و یکپارچگی داده محافظت می‌کند.
• External System: سامانه بیرونی مانند درگاه پرداخت یا سرویس پیامک.
• Hotspot: نقطه مبهم، متناقض یا پرریسک در فرایند.

مراحل اجرای کارگاه

1. محدوده جلسه را مشخص کنید؛ کل کسب‌وکار، یک فرایند یا یک زیرسیستم.
2. افرادی را دعوت کنید که فرایند را واقعاً می‌شناسند.
3. تمام رویدادهای مهم را بدون نگرانی درباره ترتیب اولیه ثبت کنید.
4. رویدادها را به ترتیب زمانی مرتب کنید.
5. فرمان، بازیگر و قانون مربوط به هر رویداد را تعیین کنید.
6. خطاها، استثناها و نقاط ابهام را علامت‌گذاری کنید.
7. خوشه‌های معنایی و مرزهای احتمالی زیرسیستم‌ها را شناسایی کنید.
8. سناریوهای عادی و غیرعادی را جداگانه بررسی کنید.

ReservationWindowOpened ReservationRequested WalletAmountBlocked ReservationWindowClosed AllocationStarted AppointmentAllocated WaitingListEntryCreated ReservationRejected NotificationRequested NotificationDelivered AppointmentCancelled WaitingUserPromoted

مزایای Event Storming

• دانش پنهان افراد را آشکار می‌کند.
• اختلاف برداشت میان واحدها را زودتر نشان می‌دهد.
• فرایند واقعی را از روی رفتار کسب‌وکار استخراج می‌کند.
• نقاط پرریسک و استثناها را پیش از کدنویسی مشخص می‌کند.
• پایه مناسبی برای طراحی دامنه‌محور ایجاد می‌کند.

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

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

۲ مرزبندی سیستم با Domain-Driven Design

DDD چه مسئله‌ای را حل می‌کند؟

طراحی دامنه‌محور یا Domain-Driven Design برای سیستم‌هایی مناسب است که پیچیدگی اصلی آن‌ها در قوانین کسب‌وکار قرار دارد. هدف DDD این نیست که صرفاً تعدادی Entity، Repository و Service بسازیم. هدف اصلی، ایجاد مدلی است که زبان و قوانین واقعی کسب‌وکار را منعکس کند.

زبان مشترک یا Ubiquitous Language

در DDD، توسعه‌دهندگان و متخصصان کسب‌وکار باید از زبان مشترک استفاده کنند. اگر واژه «رزرو قطعی» در جلسات یک معنی دارد اما در کد با نام‌های متفاوتی مانند ApprovedRequest، FinalOrder و AcceptedBooking پیاده‌سازی شده باشد، مدل به‌تدریج از واقعیت کسب‌وکار فاصله می‌گیرد.

زبان مشترک باید در نام کلاس‌ها، متدها، رویدادها، APIها، مستندات و حتی جلسات روزانه قابل مشاهده باشد.

Bounded Context چیست؟

زمینه محدودشده یا Bounded Context مرزی است که در داخل آن، یک مدل و مجموعه واژگان معنای مشخصی دارند. برای نمونه، مفهوم «کاربر» در زمینه احراز هویت با مفهوم همان شخص در زمینه مالی یکسان نیست.

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

نمونه مرزبندی

Context Map

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

• Identity اطلاعات هویتی موردنیاز Reservation را فراهم می‌کند.
• Reservation برای مسدودکردن مبلغ به Finance درخواست می‌دهد.
• پس از تخصیص، Reservation رویدادی برای Notification منتشر می‌کند.
• Operations فقط اطلاعات لازم برای کنترل مراجعه را دریافت می‌کند.

تحلیل تاکتیکی در DDD

پس از مرزبندی راهبردی، در بخش‌های پیچیده می‌توان از الگوهای تاکتیکی استفاده کرد:

• Entity: شیئی که هویت پایدار دارد.
• Value Object: شیئی که با مقدار خود شناخته می‌شود.
• Aggregate: مرز تراکنش و یکپارچگی دامنه.
• Domain Service: منطقی که متعلق به یک Entity خاص نیست.
• Domain Event: اتفاق مهمی که در دامنه رخ داده است.
• Repository: واسط بازیابی و ذخیره Aggregate.

۳ مستندسازی معماری با C4 Model

چرا C4 بهتر از نمودارهای مبهم است؟

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

سطوح مدل C4

1. System Context: سیستم، کاربران و سامانه‌های خارجی.
2. Container: برنامه‌ها، APIها، پایگاه داده‌ها و پردازشگرها.
3. Component: اجزای داخلی یک Container مهم.
4. Code: جزئیات سطح کد، کلاس یا ماژول.

سطح System Context

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

سطح Container

در C4، Container فقط به Docker اشاره ندارد. هر واحد اجرایی یا ذخیره‌سازی مستقل مانند Web Application، API، Worker، Mobile App، Database یا Message Broker یک Container محسوب می‌شود.

[Web Application]         |         v [Backend API]         |         +--> [Identity Module]         +--> [Reservation Module]         +--> [Finance Module]         +--> [Notification Worker]         |         +--> [Relational Database]         +--> [Message Broker]         +--> [Distributed Cache]

سطح Component

برای یک ماژول پیچیده مانند Reservation می‌توان اجزای زیر را نمایش داد:

• ReservationCommandHandler
• AllocationEngine
• WaitingListPolicy
• ReservationRepository
• DomainEventPublisher

معماری به‌عنوان کد

یکی از روش‌های جدید، نگهداری نمودارهای معماری به‌صورت کد است. ابزارهایی مانند PlantUML، Mermaid و Structurizr DSL امکان می‌دهند نمودار در مخزن کد نگهداری شود، بازبینی گردد و همراه با تغییرات سیستم تکامل پیدا کند.

مزیت این روش آن است که نمودار مانند سایر فایل‌های پروژه نسخه‌بندی می‌شود و احتمال منسوخ‌شدن آن کاهش می‌یابد.

قواعد یک نمودار معماری خوب

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

۴ تحلیل راهبردی با Wardley Mapping

Wardley Map چیست؟

نقشه واردلی یا Wardley Map روشی برای تحلیل راهبردی قابلیت‌ها و وابستگی‌های یک سیستم است. این روش فقط ساختار فنی را نشان نمی‌دهد، بلکه جایگاه هر قابلیت را از نظر میزان بلوغ و تبدیل‌شدن به یک کالای استاندارد مشخص می‌کند.

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

دو محور اصلی

• محور عمودی: میزان دیده‌شدن قابلیت برای کاربر و وابستگی به آن.
• محور افقی: مرحله تکامل از Genesis تا Custom، Product و Commodity.

کاربرد عملی

1. نیاز یا ارزش اصلی کاربر را مشخص کنید.
2. قابلیت‌های لازم برای تولید آن ارزش را فهرست کنید.
3. وابستگی میان قابلیت‌ها را رسم کنید.
4. مرحله بلوغ هر قابلیت را تعیین کنید.
5. مشخص کنید کدام بخش باید ساخته، خریداری یا برون‌سپاری شود.

مزیت Wardley Mapping

این روش کمک می‌کند تیم انرژی خود را روی بخش‌های متمایزکننده متمرکز کند و برای قابلیت‌های عمومی دوباره چرخ را اختراع نکند. همچنین در تصمیم‌گیری Build یا Buy و تعیین اولویت سرمایه‌گذاری مفید است.

۵ ثبت تصمیم‌های معماری با ADR

ADR چیست؟

ثبت تصمیم معماری یا Architecture Decision Record یک سند کوتاه است که یک تصمیم مهم معماری، دلایل آن، گزینه‌های دیگر و پیامدهای انتخاب را ثبت می‌کند.

نمودار معماری نشان می‌دهد سیستم چگونه ساخته شده است؛ اما ADR توضیح می‌دهد چرا این ساختار انتخاب شده است. این موضوع زمانی اهمیت پیدا می‌کند که اعضای جدید وارد پروژه شوند یا تیم بخواهد تصمیمی قدیمی را بازبینی کند.

ساختار پیشنهادی ADR

# ADR-014: Asynchronous Notification Delivery  Status: Accepted Date: 2026-07-27  ## Context Reservation processing may generate thousands of notification requests. External messaging providers can be slow or unavailable.  ## Decision Reservation publishes NotificationRequested events. A separate worker sends messages through configured channels.  ## Alternatives 1. Send messages inside the reservation transaction. 2. Call notification service synchronously. 3. Store messages and process them periodically.  ## Consequences Positive: - Reservation is not blocked by messaging providers. - Failed deliveries can be retried. - Notification scales independently.  Negative: - Delivery is eventually consistent. - Monitoring and deduplication are required.

چه تصمیم‌هایی باید ثبت شوند؟

• انتخاب Monolith، Modular Monolith یا Microservices.
• انتخاب ارتباط هم‌زمان یا غیرهم‌زمان.
• مالکیت داده و مرز پایگاه‌های داده.
• روش احراز هویت و مجوزدهی.
• استفاده از Message Broker، Cache یا Search Engine.
• راهبرد تراکنش توزیع‌شده.
• انتخاب فناوری‌ای که تغییر آن پرهزینه است.

ویژگی‌های ADR خوب

• کوتاه و قابل‌خواندن است.
• شرایط زمان تصمیم را توضیح می‌دهد.
• گزینه‌های ردشده را ثبت می‌کند.
• پیامدهای مثبت و منفی را صادقانه می‌نویسد.
• وضعیت آن مشخص است؛ Proposed، Accepted، Superseded یا Deprecated.

۶ تحلیل اجتماعی ـ فنی با Team Topologies

رابطه ساختار تیم و معماری

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

چهار نوع اصلی تیم

1. Stream-aligned Team: مالک یک جریان ارزش مشخص.
2. Platform Team: ارائه‌دهنده قابلیت‌های مشترک داخلی.
3. Enabling Team: کمک موقت برای یادگیری یا حل یک چالش تخصصی.
4. Complicated Subsystem Team: مالک یک زیرسیستم با دانش عمیق تخصصی.

بار شناختی

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

نشانه‌های بار شناختی بالا

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

پرسش‌های تحلیلی

1. کدام تیم مالک هر Bounded Context است؟
2. برای انتشار یک قابلیت چند تیم باید هماهنگ شوند؟
3. کدام تیم مسئول بخش‌های نامرتبط است؟
4. کدام سرویس مالک مشخص ندارد؟
5. آیا پلتفرم داخلی واقعاً کار تیم‌ها را آسان کرده است؟
6. آیا مرزهای تیمی و مرزهای معماری هم‌راستا هستند؟

۷ تحلیل امنیت با Threat Modeling

Threat Modeling چیست؟

مدل‌سازی تهدید یا Threat Modeling روشی ساختاریافته برای شناسایی تهدیدها پیش از وقوع است. به‌جای آن‌که امنیت پس از تکمیل سیستم بررسی شود، در همان مرحله تحلیل و طراحی پرسیده می‌شود:

• از چه چیزی محافظت می‌کنیم؟
• چه مهاجمی ممکن است به آن حمله کند؟
• مسیرهای حمله کدام‌اند؟
• پیامد هر حمله چیست؟
• چه کنترل‌هایی ریسک را کاهش می‌دهند؟

روش STRIDE

مراحل تحلیل تهدید

1. دارایی‌های مهم را مشخص کنید.
2. مرزهای اعتماد را روی نمودار معماری علامت بزنید.
3. جریان داده را میان اجزا رسم کنید.
4. برای هر جریان و جزء، تهدیدهای STRIDE را بررسی کنید.
5. شدت و احتمال تهدید را ارزیابی کنید.
6. کنترل‌های پیشگیرانه، تشخیصی و اصلاحی تعریف کنید.
7. تهدیدها را به تست و معیار پذیرش تبدیل کنید.

۸ تحلیل زمان اجرا با Observability

تفاوت Monitoring و Observability

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

سیگنال‌های اصلی

چگونه Observability به تحلیل کمک می‌کند؟

• وابستگی‌های واقعی سرویس‌ها را آشکار می‌کند.
• نقاط کند در زنجیره درخواست را نشان می‌دهد.
• خطاهای ناشی از سرویس خارجی را از خطای داخلی جدا می‌کند.
• نشان می‌دهد کدام قابلیت بیشترین بار را تولید می‌کند.
• فرضیات معماری را با داده واقعی مقایسه می‌کند.
• ظرفیت‌سنجی و برنامه‌ریزی مقیاس را دقیق‌تر می‌کند.

Correlation ID و Distributed Tracing

در سیستم‌های توزیع‌شده، یک درخواست ممکن است از چند API، Worker و Message Broker عبور کند. استفاده از Correlation ID و Distributed Trace باعث می‌شود تمام عملیات مرتبط با یک درخواست در کنار هم دیده شوند.

TraceId: 7f13a8... WebApp -> API Gateway -> Reservation Service         -> Finance Service -> Message Broker         -> Notification Worker -> SMS Provider

شاخص‌های کسب‌وکاری

Observability نباید فقط به CPU و حافظه محدود شود. شاخص‌های کسب‌وکاری نیز باید ثبت شوند:

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

۹ کنترل تکامل با Architecture Fitness Functions

Fitness Function چیست؟

تابع برازندگی معماری یا Architecture Fitness Function یک معیار یا آزمون خودکار است که بررسی می‌کند سیستم همچنان ویژگی معماری موردنظر را حفظ کرده است یا خیر.

به‌جای آن‌که فقط در سند بنویسیم «لایه Domain نباید به Infrastructure وابسته باشد»، این قانون را با یک تست معماری کنترل می‌کنیم.

نمونه قوانین قابل‌آزمایش

• Domain نباید به Infrastructure وابسته باشد.
• هیچ ماژولی نباید مستقیماً جدول ماژول دیگر را تغییر دهد.
• تمام APIهای حساس باید Authorization داشته باشند.
• زمان پاسخ عملیات حیاتی باید کمتر از حد مشخص باشد.
• سرویس‌ها نباید وابستگی چرخه‌ای داشته باشند.
• تمام رویدادهای مهم باید قابلیت Trace داشته باشند.
• پوشش تست ماژول‌های بحرانی نباید از حد تعیین‌شده کمتر شود.

نمونه مفهومی تست معماری در .NET

[Fact] public void Domain_Should_Not_Depend_On_Infrastructure() {     var result = Types         .InAssembly(typeof(DomainAssemblyMarker).Assembly)         .ShouldNot()         .HaveDependencyOn("MySystem.Infrastructure")         .GetResult();      Assert.True(result.IsSuccessful); }

مزیت Fitness Functions

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

روش ترکیبی پیشنهادی برای یک پروژه واقعی

هیچ‌یک از روش‌های معرفی‌شده به‌تنهایی کافی نیست. بهترین نتیجه زمانی ایجاد می‌شود که این روش‌ها در یک جریان منسجم به کار روند.

1. تعریف مسئله و اهداف: محدوده سیستم، کاربران، اهداف کسب‌وکار و ویژگی‌های کیفی اولیه مشخص شوند.
2. برگزاری Event Storming: رویدادها، فرایندها، قوانین و نقاط مبهم کشف شوند.
3. استخراج Bounded Contextها: مرزهای دامنه، زبان مشترک و مالکیت داده تعیین گردد.
4. رسم Context Map: نوع ارتباط و وابستگی میان زمینه‌ها مشخص شود.
5. تهیه نمودار C4: نمای کلان، Containerها و اجزای مهم معماری ترسیم شوند.
6. تهیه Wardley Map: قابلیت‌های متمایزکننده از قابلیت‌های عمومی جدا شوند.
7. طراحی تیم‌ها: مالکیت زمینه‌ها و شیوه تعامل تیم‌ها تعیین شود.
8. ثبت ADR: تصمیم‌های مهم و پیامدهای آن‌ها مستند شوند.
9. مدل‌سازی تهدید: مرزهای اعتماد، تهدیدها و کنترل‌ها بررسی شوند.
10. تعریف Observability: Trace، Metric، Log و شاخص‌های کسب‌وکاری طراحی شوند.
11. تعریف Fitness Functions: قواعد کلیدی معماری به تست خودکار تبدیل شوند.
12. بازبینی دوره‌ای: مدل‌ها با رفتار واقعی سیستم و تغییرات کسب‌وکار تطبیق داده شوند.

مثال جامع: تحلیل یک سامانه ملی رزرو نوبت

شرح مسئله

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

خروجی Event Storming

• درخواست ثبت شد.
• مبلغ مسدود شد.
• بازه رزرو بسته شد.
• پردازش تخصیص آغاز شد.
• نوبت قطعی شد.
• کاربر وارد لیست انتظار شد.
• مبلغ آزاد شد.
• پیام ارسال شد.
• نوبت لغو شد.
• فرد جدید از لیست انتظار جایگزین شد.

Bounded Contextهای پیشنهادی

• Identity
• Profile Management
• Scheduling
• Reservation
• Allocation
• Finance
• Notification
• Operations
• Reporting

تصمیم معماری

برای نسخه اولیه می‌توان از Modular Monolith استفاده کرد، مشروط بر آن‌که هر زمینه ماژول مستقل، قرارداد مشخص و مالکیت داده شفاف داشته باشد. پردازش پیام و تخصیص می‌تواند به Workerهای جدا منتقل شود. اگر در آینده نیاز به مقیاس‌پذیری مستقل یا استقرار جداگانه ایجاد شد، برخی ماژول‌ها قابل استخراج خواهند بود.

نمونه ADRهای لازم

• انتخاب Modular Monolith برای نسخه نخست.
• استفاده از Outbox Pattern برای انتشار مطمئن رویدادها.
• ارسال غیرهم‌زمان پیام‌ها.
• مالکیت مستقل داده توسط هر ماژول.
• استفاده از الگوریتم Batch برای تخصیص پس از پایان بازه.

تهدیدهای مهم

• ارسال چندباره درخواست رزرو.
• دست‌کاری مبلغ یا شناسه نوبت.
• رزرو با هویت جعلی.
• حمله انکار سرویس در زمان بازشدن رزرو.
• دسترسی اپراتور یک منطقه به اطلاعات منطقه دیگر.
• ارسال تکراری پیام و کسر هزینه چندباره.

Fitness Functionهای پیشنهادی

• ماژول Reservation نباید مستقیماً جدول Finance را تغییر دهد.
• تمام فرمان‌های مالی باید Idempotent باشند.
• تمام APIهای مدیریتی باید مجوز مشخص داشته باشند.
• پردازش تخصیص باید در حجم تعیین‌شده در زمان مجاز تمام شود.
• هیچ پیام دامنه‌ای بدون Correlation ID منتشر نشود.

جدول مقایسه روش‌ها

اشتباهات رایج در تحلیل سیستم‌های بزرگ

۱. شروع تحلیل از دیتابیس

طراحی جداول پیش از شناخت دامنه باعث می‌شود ساختار داده، مدل کسب‌وکار را تحمیل کند. ابتدا باید رویدادها، قوانین، مرزها و مالکیت داده شناخته شوند.

۲. تبدیل هر ماژول به Microservice

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

۳. تولید مستندات حجیم و ثابت

سندی که به‌روزرسانی نمی‌شود، به‌سرعت بی‌اعتماد خواهد شد. مستندات باید کوتاه، هدفمند، نسخه‌بندی‌شده و نزدیک به کد باشند.

۴. نادیده گرفتن ویژگی‌های کیفی

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

۵. بی‌توجهی به تیم‌ها

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

۶. تحلیل فقط برای شرایط عادی

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

۷. ثبت‌نکردن تصمیم‌ها

بدون ADR، تیم‌های آینده ممکن است محدودیت‌ها و دلایل تصمیم را ندانند و همان بحث‌ها را دوباره تکرار کنند.

بهترین روش‌ها

1. تحلیل را با مسئله کسب‌وکار آغاز کنید، نه فناوری.
2. از افراد واقعی دامنه در جلسات استفاده کنید.
3. مرز دامنه، داده، تیم و استقرار را با هم بررسی کنید.
4. مدل‌ها را ساده و متناسب با مخاطب نگه دارید.
5. تصمیم‌های مهم را همان زمان ثبت کنید.
6. ویژگی‌های کیفی را به معیار قابل‌اندازه‌گیری تبدیل کنید.
7. سناریوهای شکست و بازیابی را هم‌زمان با مسیر موفق تحلیل کنید.
8. نمودارها و ADRها را در مخزن نسخه‌بندی نگه دارید.
9. معماری را با داده‌های Observability اعتبارسنجی کنید.
10. قواعد مهم را با Fitness Function خودکار کنید.
11. به‌جای بازطراحی بزرگ، بهبودهای تدریجی و قابل‌اندازه‌گیری انجام دهید.

پرسش‌های متداول

آیا UML دیگر کاربرد ندارد؟

خیر. UML همچنان برای نمایش دقیق برخی رفتارها و ساختارها مفید است. مشکل زمانی ایجاد می‌شود که از UML به‌عنوان تنها ابزار تحلیل استفاده شود. نمودار Sequence، State Machine و Activity در محل مناسب ارزشمند هستند.

آیا DDD فقط برای Microservices است؟

خیر. DDD مستقل از سبک استقرار است. می‌توان آن را در Modular Monolith، Microservices یا حتی یک برنامه دسکتاپ پیچیده استفاده کرد.

بهترین روش برای شروع کدام است؟

برای پروژه‌ای که دامنه آن مبهم است، Event Storming نقطه شروع مناسبی است. پس از آن می‌توان Bounded Contextها را استخراج و با C4 معماری را نمایش داد.

آیا همه پروژه‌ها به Wardley Map نیاز دارند؟

خیر. این روش زمانی بیشترین ارزش را دارد که تصمیم‌های Build یا Buy، سرمایه‌گذاری فناوری و اولویت قابلیت‌ها مطرح باشد.

آیا ADR باید طولانی باشد؟

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

چه زمانی باید سیستم را به Microservices تبدیل کرد؟

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

جمع‌بندی

چک‌لیست نهایی تحلیل سیستم بزرگ

1. آیا اهداف و محدوده سیستم مشخص هستند؟
2. آیا متخصصان واقعی دامنه در تحلیل حضور دارند؟
3. آیا رویدادها و سناریوهای استثنایی کشف شده‌اند؟
4. آیا زبان مشترک تعریف شده است؟
5. آیا Bounded Contextها و مالکیت داده مشخص‌اند؟
6. آیا Context Map تهیه شده است؟
7. آیا نمودارهای Context و Container وجود دارند؟
8. آیا قابلیت‌های متمایزکننده از قابلیت‌های عمومی جدا شده‌اند؟
9. آیا تصمیم‌های مهم در ADR ثبت شده‌اند؟
10. آیا هر بخش مالک تیمی مشخص دارد؟
11. آیا بار شناختی تیم‌ها بررسی شده است؟
12. آیا مرزهای اعتماد و تهدیدهای امنیتی تحلیل شده‌اند؟
13. آیا Trace، Metric و Log طراحی شده‌اند؟
14. آیا شاخص‌های کسب‌وکاری قابل‌اندازه‌گیری هستند؟
15. آیا قوانین اصلی معماری به تست خودکار تبدیل شده‌اند؟
16. آیا مدل‌ها به‌صورت دوره‌ای با سیستم واقعی تطبیق داده می‌شوند؟