معماری فریادزن (Screaming Architecture) 📢

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

معماری شما باید بیانگر مشکلاتی باشد که حل می‌کند. سازماندهی سیستم شما حول موارد استفاده (use cases)، به ساختاری منجر می‌شود که با دامنه کسب‌وکار (business domain) هماهنگ است. این رویکرد معماری فریادزن نامیده می‌شود.

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

در این مقاله، می‌خواهم چند مثال عملی نشان دهم و در مورد مزایای معماری فریادزن بحث کنم.

یک رویکرد مبتنی بر مورد استفاده (Use Case Driven) 🎯

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

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

آیا آن‌ها فریاد می‌زنند: سیستم رزرو آپارتمان یا سیستم بلیت‌فروشی؟

یا فریاد می‌زنند ASP.NET Core؟

در اینجا یک مثال از ساختار پوشه‌ای که حول دغدغه‌های فنی سازماندهی شده، آمده است: 👎

📁 Api/
| 📁 Controllers
| 📁 Entities
| 📁 Repositories
| 📁 Services
| #️⃣ ApartmentService.cs
| #️⃣ BookingService.cs
| 📁 Models

شما متوجه خواهید شد که انسجام (cohesion) با این ساختار پوشه پایین است.

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

📁 Api/
| 📁 Apartments
| 📁 ReserveApartment
| 📁 Bookings
| 📁 CancelBooking
| 📁 Payments
| 📁 Reviews

مزایای معماری فریادزن ✅

• انسجام بهبود یافته چون موارد استفاده مرتبط به هم نزدیک هستند.

• اتصال بالا (High coupling) برای یک مورد استفاده واحد و موارد استفاده مرتبط با آن.

• اتصال سست (Low coupling) بین موارد استفاده نامرتبط.

• ناوبری آسان‌تر در سراسر سولوشن.

Bounded Contextها و برش‌های عمودی 🧩

ما تکنیک‌های زیادی برای کشف ماژول‌های سطح بالا در سیستم خود داریم. برای مثال، می‌توانیم از event storming برای کاوش موارد استفاده سیستم استفاده کنیم.

ایده کلی در اینجا، فکر کردن در مورد انسجام حول عملکردهاست. Bounded contextها، برش‌های عمودی، و معماری فریادزن مفاهیم مکمل یکدیگر هستند.

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

📁 Modules/
| 📁 Ticketing
| 📁 Application
| 📁 Carts
| 📁 AddItemToCart
| 📁 ClearCart
| 📁 Orders
| 📁 SubmitOrder
| 📁 Domain
| 📁 Customers
| 📁 Orders
| 📁 infrastructure
| 📁 Authentication
| 📁 Customers

نکات پایانی 📝

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

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

🔖 هشتگ‌ها:
#SoftwareArchitecture #ScreamingArchitecture #DomainDrivenDesign #VerticalSliceArchitecture