‏Clean Architecture در ربات تلگرام چطور کمک می‌کند؟ 🧱🤖

وقتی ربات پیچیده می‌شود (مثلاً پرداخت، مدیریت کاربر، پنل ادمین)، اگر همه‌چیز را توی یک فایل bot.py بنویسیم، بعد از مدتی هیچ‌کس حتی خودِ ما هم نمی‌فهمیم چی به چیه 😅

اینجاست که ایده‌ٔ Clean Architecture وارد می‌شود: جدا کردن لایه‌ها تا Telegram فقط «درگاه ورودی» باشد، نه قلب منطق برنامه.

به‌صورت ساده، می‌توانیم چند لایهٔ مهم در ربات در نظر بگیریم:

• Domain (Business Logic): قوانین اصلی ربات (مثلاً: کاربر عادی حق دسترسی به فلان فرمان را ندارد).
• Application / Use Cases: سناریوها (مثلاً: "ثبت سفارش"، "ثبت کاربر جدید").
• Infrastructure: چیزهای وابسته به دنیا بیرون: Telegram Bot API، Database، Redis، HTTP و ...
• Interface / Delivery: هندلرهای پیام، Webhook، CLI و غیره.

نکتهٔ مهم این است که داخلی‌ها بیرونی‌ها را نمی‌شناسند. یعنی منطق اصلی ربات، نباید مستقیم به python-telegram-bot یا aiogram وابسته باشد.

مثال ساده با Python (الگو، نه کد نهایی پروداکشن):

"""domain/entities.py"""
from dataclasses import dataclass

@dataclass
class User:
    id: int
    username: str | None
    is_admin: bool = False


"""domain/services.py"""
from .entities import User

class AccessService:
    def can_use_admin_panel(self, user: User) -> bool:
        return user.is_admin


"""application/use_cases.py"""
from .dto import MessageDTO
from domain.services import AccessService

class HandleAdminCommand:
    def __init__(self, access_service: AccessService):
        self._access = access_service

    def execute(self, msg: MessageDTO) -> str:
        if not self._access.can_use_admin_panel(msg.user):
            return "دسترسی غیرمجاز ❌"
        return "خوش اومدی ادمین 👋"


"""infrastructure/telegram_handlers.py"""
from aiogram import Router, types
from application.use_cases import HandleAdminCommand
from application.dto import MessageDTO

router = Router()

handle_admin = HandleAdminCommand(access_service=...)

@router.message(commands=["admin"])
async def admin_handler(message: types.Message):
    dto = MessageDTO(
        user_id=message.from_user.id,
        username=message.from_user.username,
        text=message.text,
    )
    reply_text = handle_admin.execute(dto)
    await message.answer(reply_text)

اینجا Use Case هیچ وابستگی مستقیمی به aiogram ندارد و فقط با یک MessageDTO کار می‌کند. این یعنی:

• راحت‌تر تست واحد (Unit Test) می‌نویسیم ✅
• اگر روزی از aiogram به کتابخانهٔ دیگری مهاجرت کنیم، منطق اصلی ربات تقریباً دست‌نخورده می‌ماند ✅
• ساختن چند نوع ورودی (Webhook، Polling، حتی CLI) ساده‌تر می‌شود ✅

برای درک عمیق‌تر ایده، نگاه به مقالهٔ اصلی Uncle Bob بسیار کمک می‌کند:
لینک مقاله Clean Architecture

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

🔖 #TelegramBot #ربات #تلگرام #Clean_Architecture #Telegram_Bot #Python #aiogram #Design_Pattern #Architecture

👤 Developix

💎 Channel: @DevelopixRobot