𝗠𝗮𝘀𝘁𝗲𝗿𝗶𝗻𝗴 𝗘𝘃𝗲𝗻𝘁-𝗗𝗿𝗶𝘃𝗲𝗻 𝗗𝗲𝗰𝗼𝘂𝗽𝗹𝗶𝗻𝗴 𝗶𝗻 𝗟𝗮𝗿𝗮𝘃𝗲𝗹

আপনার Laravel কন্ট্রোলারগুলো প্রায়শই বিজনেস লজিকের (business logic) স্তূপ বা ডাম্পিং গ্রাউন্ড হয়ে ওঠে।

আপনি একটি সাধারণ রেজিস্ট্রেশন ফ্লো দিয়ে শুরু করেন। শীঘ্রই, আপনি একটি মাত্র মেথডের মধ্যে ইমেল নোটিফিকেশন, Slack অ্যালার্ট, অডিট লগ এবং API কল যুক্ত করে ফেলেন। এটি একটি 'fat controller' তৈরি করে।

Fat controller আপনার কোডকে ভঙ্গুর (fragile) করে তোলে। এগুলো টেস্ট করা কঠিন। এগুলো Single Responsibility Principle লঙ্ঘন করে।

এটি ঠিক করার জন্য আপনার RabbitMQ-এর মতো জটিল টুলের প্রয়োজন নেই। Laravel-এর নিজস্ব একটি বিল্ট-ইন ইভেন্ট সিস্টেম রয়েছে যা বেশিরভাগ প্রয়োজনে কাজ করে।

Tight coupling-এর সমস্যাগুলো: যদি একটি নিউজলেটার API ধীরগতির হয়, তবে আপনার ইউজার রেজিস্ট্রেশনও ধীর হয়ে যায়। যদি একটি মেইল সার্ভিস ব্যর্থ হয়, তবে পুরো রিকোয়েস্টটিই ব্যর্থ হয়।

সমাধান: Event-Driven Architecture।

ইভেন্টগুলো একটি মিডল লেয়ার হিসেবে কাজ করে। আপনার কন্ট্রোলার একটি অ্যাকশন ঘোষণা করে। লিসেনারগুলো (Listeners) স্বাধীনভাবে সেই অ্যাকশনে প্রতিক্রিয়া জানায়।

একটি লিন (lean) কন্ট্রোলার দেখতে এমন হয়:

public function register(RegisterRequest $request)
{
    $user = User::create($request->validated());

    UserRegistered::dispatch($user);

    return response()->json(['message' => 'Success'], 201);
}

কন্ট্রোলারটি এখন শুধুমাত্র ডেটা পারসিস্টেন্স (data persistence) হ্যান্ডেল করে। এটি সাইড ইফেক্ট (side effects) নিয়ে মাথা ঘামায় না।

আপনি তিনটি প্রধান সুবিধা পাবেন:

• পারফরম্যান্স: ব্যবহারকারীরা তাৎক্ষণিকভাবে রেসপন্স পান। ShouldQueue ইন্টারফেস ব্যবহার করে ভারী কাজগুলো ব্যাকগ্রাউন্ডে চলে।
• রেজিলিয়েন্স (Resilience): যদি কোনো সার্ভিস ডাউন থাকে, তবে লিসেনার মূল অ্যাপ্লিকেশনটি নষ্ট না করেই কাজটি পুনরায় চেষ্টা (retry) করতে পারে।
• এক্সটেনসিবিলিটি (Extensibility): আপনি একটি নতুন লিসেনার যোগ করার মাধ্যমে পুশ নোটিফিকেশনের মতো নতুন ফিচার যোগ করতে পারেন। আপনাকে মূল কন্ট্রোলারটি পরিবর্তন করতে হবে না।

অনুসরণীয় সেরা অনুশীলনসমূহ (Best practices):

• সাইড ইফেক্টের ওপর গুরুত্ব দিন: পোস্ট-প্রসেসিংয়ের জন্য ইভেন্ট ব্যবহার করুন। যে কোর লজিক তাৎক্ষণিকভাবে সম্পন্ন হওয়া প্রয়োজন, সেটির জন্য ইভেন্ট ব্যবহার করবেন না।
• বর্ণনামূলক নাম ব্যবহার করুন: OrderPlaced বা UserRegistered-এর মতো পাস্ট-টেনস (past-tense) নাম ব্যবহার করুন। এটি নির্দেশ করে যে কাজটি ইতিমধ্যে সম্পন্ন হয়েছে।
• অতিরিক্ত অ্যাবস্ট্রাকশন (over-abstraction) এড়িয়ে চলুন: যদি কোডের একটি অংশ সহজ হয় এবং কেবল এক জায়গায় ব্যবহৃত হয়, তবে ইভেন্টের চেয়ে একটি ফাংশন কল করা ভালো।

ডেটাবেস পরিবর্তনের জন্য Eloquent Observers ব্যবহার করুন। বিজনেস অ্যাকশনের জন্য Events ব্যবহার করুন।

ইভেন্টে রিফ্যাক্টর করা মানে হলো স্থায়িত্ব নিশ্চিত করা। এটি আপনার কোডকে ডিবাগ করা সহজ এবং টেস্ট করা দ্রুত করে তোলে।

আজই আপনার কন্ট্রোলারের একটি জটিল বা 'noisy' সাইড ইফেক্ট বেছে নিন এবং সেটিকে একটি লিসেনারে স্থানান্তর করুন।

এই স্যান্ডবক্স উদাহরণটি চেষ্টা করে দেখুন: https://onlinephp.io/c/1f7b2

ফ্যাট কন্ট্রোলার থেকে দূরে: লারাভেলে ইভেন্ট-ড্রিভেন ডিকাপলিংয়ে দক্ষতা অর্জন

সমস্যা: "ফ্যাট কন্ট্রোলার" অ্যান্টি-প্যাটার্ন

আপনার লারাভেল অ্যাপ্লিকেশনটি যখন বড় হতে থাকে, আপনি হয়তো লক্ষ্য করবেন যে আপনার কন্ট্রোলারগুলো দিন দিন অনেক বেশি Bloated বা জটিল হয়ে উঠছে। এটি একটি সাধারণ ঘটনা যা "Fat Controller" অ্যান্টি-প্যাটার্ন হিসেবে পরিচিত। একটি ফ্যাট কন্ট্রোলার হলো এমন একটি কন্ট্রোলার যা অনেক বেশি দায়িত্ব পালন করে—যেমন রিকোয়েস্ট ভ্যালিডেশন করা, ডাটাবেসের সাথে কাজ করা, থার্ড-পার্টি এপিআই কল করা, ইমেইল পাঠানো এবং আরও অনেক কিছু—সবই একটি মাত্র মেথডের মধ্যে। এর ফলে কোড টেস্ট করা, মেইনটেইন করা এবং স্কেল করা অত্যন্ত কঠিন হয়ে পড়ে।

সমাধান: ইভেন্ট-ড্রিভেন আর্কিটেকচারের মাধ্যমে ডিকাপলিং

ডিকাপলিং (Decoupling) হলো আপনার অ্যাপ্লিকেশনের বিভিন্ন অংশের মধ্যে নির্ভরশীলতা (dependency) কমিয়ে আনার একটি প্রক্রিয়া। যখন একটি অংশ অন্য একটি অংশের ওপর সরাসরি নির্ভর না করে, তখন আমরা বলি যে তারা 'decoupled'। ডিকাপলিংয়ের ক্ষেত্রে একটি অংশ অন্য একটি অংশকে সরাসরি কল করার পরিবর্তে, তারা ইভেন্টের মাধ্যমে যোগাযোগ করে।

ইভেন্ট-ড্রিভেন আর্কিটেকচার (Event-Driven Architecture - EDA) আপনাকে আপনার অ্যাপ্লিকেশনে কোনো গুরুত্বপূর্ণ ঘটনা ঘটলে একটি ইভেন্ট ট্রিগার করার সুবিধা দেয়। সিস্টেমের অন্যান্য অংশ সেই ইভেন্টের জন্য "listen" করতে পারে এবং সেই অনুযায়ী কাজ করতে পারে, যেখানে মূল অংশটি জানতেই পারে না যে অন্য কোনো অংশ সেই কাজ করছে।

লারাভেলে ইভেন্ট এবং লিসেনার ইমপ্লিমেন্ট করা

লারাভেল তার বিল্ট-ইন Event এবং Listener ক্লাসগুলোর মাধ্যমে এই প্যাটার্নটি ইমপ্লিমেন্ট করা অত্যন্ত সহজ করে তুলেছে।

ধাপ ১: একটি ইভেন্ট তৈরি করা

একটি ইভেন্ট হলো একটি সাধারণ ক্লাস যা ঘটা ঘটনার সাথে সম্পর্কিত ডাটা ধারণ করে। php artisan make:event UserRegistered

ধাপ ২: একটি লিসেনার তৈরি করা

একটি লিসেনার হলো এমন একটি ক্লাস যা ইভেন্টটি ফায়ার হওয়ার পর নির্দিষ্ট কাজ সম্পন্ন করে। php artisan make:listener SendWelcomeEmail --event=UserRegistered

ধাপ ৩: সেগুলো রেজিস্টার করা

লারাভেলে, আপনি এগুলো EventServiceProvider-এ রেজিস্টার করেন।

ব্যবহারিক উদাহরণ: ইউজার রেজিস্ট্রেশন

চলুন একটি "ফ্যাট কন্ট্রোলার" এবং একটি "ইভেন্ট-ড্রিভেন" পদ্ধতির মধ্যে পার্থক্য দেখি।

ফ্যাট কন্ট্রোলার পদ্ধতি (খারাপ অভ্যাস)

public function store(Request $request)
{
    // ১. রিকোয়েস্ট ভ্যালিডেশন
    $validated = $request->validate([...]);

    // ২. ইউজার তৈরি করা
    $user = User::create($validated);

    // ৩. ওয়েলকাম ইমেইল পাঠানো
    Mail::to($user)->send(new WelcomeEmail($user));

    // ৪. ইউজার প্রোফাইল তৈরি করা
    Profile::create(['user_id' => $user->id]);

    // ৫. অ্যাক্টিভিটি লগ করা
    Log::info('New user registered: ' . $user->email);

    return redirect()->route('dashboard');
}

ইভেন্ট-ড্রিভেন পদ্ধতি (সেরা অভ্যাস)

public function store(Request $request)
{
    // ১. রিকোয়েস্ট ভ্যালিডেশন
    $validated = $request->validate([...]);

    // ২. ইউজার তৈরি করা
    $user = User::create($validated);

    // ৩. ইভেন্ট ট্রিগার করা
    event(new UserRegistered($user));

    return redirect()->route('dashboard');
}

এখন, UserRegistered ইভেন্টটি একাধিক লিসেনার ট্রিগার করতে পারে:

• SendWelcomeEmail
• CreateUserProfile
• LogUserRegistration

আরও উন্নত পর্যায়ে: অবজারভার এবং কিউ (Observers and Queues)

• Observers: আপনি