وقتی ربات پیچیده می‌شود (مثلاً پرداخت، مدیریت کاربر، پنل ادمین)، اگر همه‌چیز را توی یک فایل 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