Eloquent Events vs Domain Events: ஃபிரேம்வொர்க் ஹூக்குகள் ஏன் போதுமானவை அல்ல

உங்கள் Eloquent கேட்பாளர் சரியாக இருப்பது போல் தோன்றியது: அதை Order மாடலின் saved நிகழ்வுடன் இணைத்து, ஒரு ஆர்டர் சேமிக்கப்படும் போது உறுதிப்படுத்தல் மின்னஞ்சலை அனுப்பினால் வேலை முடிந்தது. இது டெமோவில் செயல்படுகிறது. பின்னர் புரொடக்‌ஷனுக்குச் செல்லும்போது, ஒரு ஆதரவு டிக்கெட் (support ticket) வருகிறது. ஒரு வாடிக்கையாளருக்கு ஒரே வாங்குதலுக்கு இரண்டு உறுதிப்படுத்தல் மின்னஞ்சல்கள் வந்துள்ளன. மற்றொருவருக்கு ரத்துசெய்தல் அறிவிப்பு இல்லாமல் பணத்தைத் திரும்பப்பெறும் (refund) ரசீது கிடைத்துள்ளது. உங்கள் லாக்ஸை (logs) சரிபார்த்தால் தவறு எதுவும் தெரியவில்லை. மின்னஞ்சல்கள் அனுப்பப்பட்டுவிட்டன. கோட் நன்றாகவே தெரிகிறது. பிரச்சனை நுட்பமானது, மேலும் அது உங்கள் கட்டமைப்பில் (architecture) உள்ளது.

இன்று இது ஏன் முக்கியமானது (ஜூலை 2026)

2026-இல், ஒரு வார இறுதி திட்டப்பணிக்குச் செயல்பட்டு, புரொடக்‌ஷனில் உடைந்துபோகும் கோட், எப்பொழுதையும் விட அதிக விரையத்தை ஏற்படுத்தும். உங்கள் குழு ஆப் ஸ்கேல் ஆகும் என்று எதிர்பார்க்கிறது. உங்கள் வாடிக்கையாளர்கள் நம்பகத்தன்மையை எதிர்பார்க்கிறார்கள். ஃபிரேம்வொர்க் ஹூக்குகள் வசதியானவை, ஆனால் அந்த வசதி பெரும்பாலும் கட்டுப்பாட்டை இழப்பதன் மூலமே கிடைக்கிறது. உங்கள் பயன்பாடு ஒரு கருத்து-நிரூபணத்தைத் (proof-of-concept) தாண்டி வளரும்போது, மின்னஞ்சல்களை அனுப்புவது போன்ற பக்க விளைவுகளை (side effects) எவ்வாறு கையாள்வது என்பது பற்றி நீங்கள் எடுக்கும் முடிவுகள், உங்கள் ஆப் பராமரிக்கக்கூடியதாக இருக்குமா அல்லது மறைமுகச் சார்புகளின் (implicit dependencies) புதிராக மாறுமா என்பதைத் தீர்மானிக்கின்றன.

Eloquent நிகழ்வுகளின் ஈர்ப்பு

Eloquent நிகழ்வுகள் எளிதான வழி. Laravel-ன் ORM உங்களுக்கு ஆயுட்கால ஹூக்குகளைத் (lifecycle hooks) தருகிறது: creating, created, updating, updated, saved, deleted. நீங்கள் ஒரு கேட்பாளரைப் பதிவுசெய்கிறீர்கள், நிகழ்வு நடக்கும் போது அது இயங்குகிறது (fires). அமைப்பமைத்தல் (configuration) எதுவுமில்லை, சிரமமும் இல்லை.

Order::saved(function ($order) {
    Mail::send(new OrderConfirmation($order));
});

வெளிப்புறப் பார்வைக்கு இது தூய்மையான கோட் (clean code). நோக்கம் தெளிவானது: ஒரு ஆர்டர் சேமிக்கப்படும் போது, உறுதிப்படுத்தலை அனுப்பவும். இது செயல்படுகிறது. மேலும் ஒரு எளிய திட்டப்பணிக்கு அது போதுமானது. ஆனால் பல கேட்பாளர்கள் இருக்கும்போதோ அல்லது ஒரே மாடல் வெவ்வேறு காரணங்களுக்காகச் சேமிக்கப்படும்போதோ சிக்கல் உருவாகிறது.

மறைக்கப்பட்ட பிரச்சனை: நோக்கம் மற்றும் சூழல்

இங்குதான் விஷயங்கள் சிக்கலாகின்றன. Eloquent-ன் saved நிகழ்வு, ஆர்டர் ஏன் சேமிக்கப்பட்டது என்பதைப் பொருட்படுத்தாமல், அது சேமிக்கப்படும் போதெல்லாம் இயங்குகிறது. ஒருவேளை நீங்கள் அதை உருவாக்கியிருக்கலாம். அல்லது 'pending' நிலையிலிருந்து 'confirmed' நிலைக்கு மாற்றியிருக்கலாம். அல்லது விநியோக முகவரியை (shipping address) புதுப்பித்திருக்கலாம். saved நிகழ்வு அதைப் பற்றிக் கவலைப்படுவதில்லை—அது எப்போதும் போல இயங்குகிறது.

இப்போது இந்தச் சூழலைக் கற்பனை செய்து பாருங்கள். ஒரு ரீஃபண்ட் செயல்முறை ஆர்டரை ஒரு refunded நிலையுடன் சேமிக்கிறது. ஒரு தனி செயல்முறை—ஒருவேளை திட்டமிடப்பட்ட ஜாப் (scheduled job), அல்லது உங்கள் கட்டணச் செயலியின் (payment processor) வெப்ஹூக் (webhook)—ஆர்டரைப் புதுப்பிக்கிறது. இரண்டும் saved நிகழ்வைத் தூண்டுகின்றன. இரண்டு கேட்பாளர்கள் இயங்குகின்றன. ஒன்று ரீஃபண்ட் மின்னஞ்சலை அனுப்புகிறது, மற்றொன்று வேறு அறிவிப்பை அனுப்புகிறது. வாடிக்கையாளருக்கு இரண்டு செய்திகளும் கிடைக்கின்றன, எது உண்மையானது என்பதில் அவர் குழப்பமடைகிறார்.

இதற்கான மூலக் காரணம் என்னவென்றால், Eloquent நிகழ்வுகள் வணிகச் செயல்பாட்டுடன் (business action) இணைக்கப்படாமல், தரவுத்தளச் செயல்பாட்டுடன் (database operation) இணைக்கப்பட்டுள்ளன. உங்கள் கோட் "ஒரு ஆர்டர் சேமிக்கப்பட்டது" என்று கூறுகிறது, ஆனால் நீங்கள் உண்மையில் சொல்வது "ஒரு ஆர்டர் உருவாக்கப்பட்டது" அல்லது "ரீஃபண்ட் வழங்கப்பட்டது" அல்லது "விநியோக விவரங்கள் புதுப்பிக்கப்பட்டன" என்பதாகும். இவை வெவ்வேறு பக்க விளைவுகளைக் கொண்ட வெவ்வேறு செயல்பாடுகள்.

ஃபிரேம்வொர்க் நிகழ்வுகள் ஸ்கேல் ஆகாது

உங்கள் பயன்பாடு வளரும்போது, இந்த பிரச்சனை மேலும் தீவிரமடைகிறது. நீங்கள் ஒரு புதிய கேட்பாளரைச் சேர்க்கிறீர்கள். அது வேலை செய்கிறது. இன்னொன்றைச் சேர்க்கிறீர்கள். இப்போது உங்களிடம் saved நிகழ்வில் ஐந்து கேட்பாளர்கள் உள்ளனர், மேலும் ஒவ்வொன்றும் என்ன செய்கிறது என்பதை உங்களால் நினைவில் வைத்திருக்க முடியாது. ஒரு பிழை தோன்றும்போது, அது எதனால் ஏற்பட்டது என்பதைக் கண்டறிய நீங்கள் ஐந்து கேட்பாளர்களையும் ஆராய வேண்டும். சார்புகள் (dependencies) மறைமுகமாகவும் உங்கள் கோட்பேஸ் முழுவதும் சிதறியும் கிடக்கின்றன.

மிக மோசமான விஷயம் என்னவென்றால், இரண்டு கேட்பாளர்கள் ஒன்றையொன்று சார்ந்திருந்தால்—ஒன்று மற்றொன்றுக்கு முன் இயங்க வேண்டும் என்றால்—அந்த வரிசையை உங்களால் கட்டாயப்படுத்த முடியாது. Eloquent அவற்றை பதிவுசெய்யப்பட்ட வரிசையில் இயக்குகிறது, இது எளிதில் உடையக்கூடியது. யாராவது ஃபைலில் தவறான இடத்தில் ஒரு கேட்பாளரைச் சேர்த்தால், பக்க விளைவுகள் தவறான வரிசையில் நிகழும்.

டொமைன் நிகழ்வுகள்: முதன்மையான நோக்கம்

டொமைன் நிகழ்வுகள் என்பது டொமைன்-டிரைவன் டிசைனிலிருந்து (DDD) பெறப்பட்ட ஒரு வித்தியாசமான அணுகுமுறையாகும். தரவுத்தளச் செயல்பாடுகளை நம்பியிருப்பதற்குப் பதிலாக, உங்கள் வணிக லாஜிக்கில் (business logic) உண்மையில் என்ன நடந்தது என்பதைக் குறிக்கும் நிகழ்வுகளை நீங்கள் வெளிப்படுத்துகிறீர்கள் (emit).

நிகழ்வுக்குப் பதிலாக, நீங்கள் ஒரு saved நிகழ்வையோ அல்லது ஒரு OrderCreated நிகழ்வையோ வெளிப்படுத்துவீர்கள். OrderRefunded ஒவ்வொரு நிகழ்வும் சூழலைத் தாங்கி நிற்கும்: என்ன நடந்தது, ஏன் நடந்தது. உங்கள் கேட்பாளர்கள் அதன்பின் தங்களுக்கான நிகழ்வுகளுக்கு சந்தா செலுத்துவார்கள் (subscribe).

class CreateOrderAction
{
    public function execute(CreateOrderRequest $request)
    {
        $order = Order::create([...]);
        
        event(new OrderCreated($order));
        
        return $order;
    }
}

இப்போது உங்கள் உறுதிப்படுத்தல் மின்னஞ்சல் கேட்பாளர் OrderCreated-க்கு மட்டுமே சந்தா செலுத்துகிறது, OrderSaved-க்கு அல்ல. ரீஃபண்ட் மின்னஞ்சல் OrderRefunded-க்கு மட்டுமே சந்தா செலுத்துகிறது. ஒவ்வொரு பக்க விளைவும் தரவுத்தளச் செயல்பாட்டுடன் அல்லாமல், அது குறிக்கும் செயல்பாட்டுடன் இணைக்கப்படுகிறது.

உங்கள் பக்க விளைவுகளைத் தனிமைப்படுத்துதல் (Decoupling)

டொமைன் நிகழ்வுகள் உங்கள் டொமைன் லாஜிக்கை ஃபிரேம்வொர்க்கிலிருந்து தனிமைப்படுத்துகின்றன (decouple). Eloquent-ன் saved நிகழ்வு என்பது ஒரு Laravel கருத்தாகும். டொமைன் நிகழ்வுகள் அப்படி அல்ல. உங்கள் வணிக லாஜிக்கை வேறு ஃபிரேம்வொர்க்கிற்கு மாற்றவோ, அல்லது கன்சோல் கமாண்டில் (console command) பயன்படுத்தவோ, அல்லது தனித்து சோதிக்கவோ நீங்கள் விரும்பினால், டொமைன் நிகழ்வுகள் அதைச் சாத்தியமாக்குகின்றன. ஃபிரேம்வொர்க் நிகழ்வுகள் அதைச் கடினமாக்குகின்றன.

டொமைன் நிகழ்வுகளுடன், உங்கள் வணிக லாஜிக் ORM-ஐச் சாராமல், ஆக்ஷன் வகுப்புகள் (action classes) அல்லது சேவைகளில் வாழ்கிறது. ஃபிரேம்வொர்க் என்பது நீங்கள் பயன்படுத்தும் ஒரு கருவியாக மாறுகிறதே தவிர, உங்கள் லாஜிக் அதனுடன் சிக்கிக்கொள்வதில்லை.

ஒரு நடைமுறை உதாரணம்: ரீஃபண்ட் செயல்முறை

ஒரு ரீஃபண்ட் செயல்முறையைக் கற்பனை செய்து பாருங்கள். செய்யப்பட வேண்டிய மூன்று விஷயங்கள் உள்ளன: ஆர்டர் நிலையைப் புதுப்பித்தல், உங்கள் வணிகக் கணக்கிலிருந்து (merchant account) பணத்தைக் கழித்தல் மற்றும் வாடிக்கையாளருக்கு ரீஃபண்ட் மின்னஞ்சலை அனுப்புதல்.

Eloquent நிகழ்வுகள் மூலம், நீங்கள் கேட்பாளர்களை saved நிகழ்வுடன் இணைப்பீர்கள். ஆனால் அது முறையற்றது. வணிகக் கணக்கு பிடித்தத்திற்கும் ஆர்டர் சேமிக்கப்படுவதற்கும் எந்தச் சம்பந்தமும் இல்லை. ரீஃபண்ட் தொடங்கப்படும்போது அது நிகழ வேண்டும்.

class ProcessRefund
{
    public function execute(Order $order, RefundDetails $details)
    {
        $order->status = 'refunded';
        $order->save();
        
        event(new OrderRefunded($order, $details));
    }
}

இப்போது நீங்கள் OrderRefunded -ஐக் கவனித்து (listen), ஒவ்வொரு விஷயத்தையும் தனியாகக் கையாளலாம். வணிகக் கணக்கு பிடித்தம், மின்னஞ்சல், கணக்கியல் பேரேடு பதிவு (accounting ledger entry)—ஒவ்வொரு கேட்பாளரும் ஒரு விஷயத்தைக் கையாள்கிறார்கள்.

மாற்றத்திற்கான பாதை

இன்றே உங்கள் அனைத்து Eloquent கேட்பாளர்களையும் நீக்க வேண்டிய அவசியமில்லை. மாற்றம் படிப்படியாக இருக்கலாம். உங்கள் ஆக்ஷன் வகுப்புகளிலிருந்து டொமைன் நிகழ்வுகளை வெளிப்படுத்தத் தொடங்குங்கள். காலப்போக்கில், கேட்பாளர்களை மாற்றவும். Eloquent கேட்பாளர்களை மாற்றீடு செய்யும் போது அவற்றை நீக்கவும்.

முடிவுரை

ஃபிரேம்வொர்க் நிகழ்வு ஹூக்குகள் வசதியானவை, ஆனால் உங்கள் கோட் வளரும்போது அவை தெளிவையும் பராமரிப்பையும் பாதிக்கும் குறுக்குவழிகளாகும். டொமைன் நிகழ்வுகளுக்குத் தொடக்கத்தில் சற்று கூடுதல் யோசனை தேவைப்படுகிறது, ஆனால் அவை நன்றாக ஸ்கேல் ஆகும். என்ன நடக்கிறது, ஏன் நடக்கிறது என்பதை அவை தெளிவாகக் கூறுகின்றன. அவை உங்கள் வணிக லாஜிக்கை ஃபிரேம்வொர்க்கிலிருந்து தனிமைப்படுத்துகின்றன. ஒரு பிழை தோன்றும் போது, எங்கு பார்க்க வேண்டும் என்பது உங்களுக்குத் தெளிவாகத் தெரியும்.

நன்மைகள்

• நிகழ்வுகள் தரவுத்தளச் செயல்பாடுகளை அல்லாமல், உண்மையான வணிகச் செயல்பாடுகளைக் குறிக்கின்றன
• எந்தச் செயல்பாடுகளுக்கு எந்தப் பக்க விளைவுகள் தூண்டப்படுகின்றன என்பதைப் புரிந்துகொள்வது எளிது
• கேட்பாளர்களுக்கு இடையே மறைமுகச் சார்புகள் (hidden dependencies) இல்லை
• ஃபிரேம்வொர்க்கைச் சாராதது—உங்கள் வணிக லாஜிக் Laravel உடன் பிணைக்கப்படவில்லை
• ஃபிரேம்வொர்க் அமைப்பு இல்லாமல் தனியாகச் சோதிக்கக்கூடியது
• கேட்பாளர்களைத் திட்டமிட்டு வரிசைப்படுத்தவும் ஒருங்கிணைக்கவும் முடியும்

குறைபாடுகள்

• ஃபிரேம்வொர்க் கேட்பாளர்களை விட அதிக பாய்லர்பிளேட் (boilerplate) கோட் தேவைப்படுகிறது
• நிகழ்வுகளை கைமுறையாக வெளிப்படுத்த வேண்டும்; தானாக நிகழாது
• மேம்பாட்டின் போது அதிக மன அழுத்தம்/சிந்தனை தேவைப்படுகிறது
• ஒழுக்கம் தேவை—ஒரு நிகழ்வை வெளிப்படுத்த மறப்பது எளிது
• நிகழ்வுகள் பதிவு செய்யப்படாவிட்டால் (logged) பிழைத்திருத்தம் (debugging) சற்று கடினமாக இருக்கும்

எச்சரிக்கை

இந்தக் கட்டுரையில் உள்ள மாதிரி கோட் மற்றும் பேட்டர்ன் பெயர்கள் பொதுவான விளக்கப்படங்களே தவிர, குறிப்பிட்ட புரொடக்‌ஷன் கோட் அல்ல. புரொடக்‌ஷனுக்கு வெளியிடுவதற்கு முன் (deploying) உங்கள் நிகழ்வு ஓட்டத்தை (event flow) முழுமையாகச் சோதிக்கவும். உங்கள் சொந்த ஆபத்தில் தொடரவும். நீங்கள் தற்போது Eloquent நிகழ்வுகளைப் பயன்படுத்துகிறீர்கள் என்றால், டொமைன் நிகழ்வுகளுக்கு மாறுவது என்பது ஒரு ரீஃபேக்டரிங் (refactoring) பணியாகும், இது உங்கள் பக்க விளைவுகளுக்கு நல்ல டெஸ்ட் கவரேஜுடன் கவனமாகச் செய்யப்பட வேண்டும்.

அடிக்கடி கேட்கப்படும் கேள்விகள்

• ஒரே செயலுக்கு எதிர்வினை ஆற்ற வேண்டிய பல டொமைன்கள் என்னிடம் இருந்தால் என்ன செய்வது?
• நிகழ்வு வரிசைமுறை மற்றும் கேட்பாளர்களுக்கு இடையிலான சார்புகளை நான் எவ்வாறு கையாள்வது?
• நான் Eloquent உடன் டொமைன் நிகழ்வுகளைப் பயன்படுத்தலாமா அல்லது வேறு ORM தேவையா?
• ஒரு நிகழ்வுக் கேட்பாளர் தோல்வியடைந்தால் என்ன நடக்கும்—முழுப் பரிவர்த்தனையும் (transaction) ரோல்பேக் ஆகுமா?
• டொமைன் நிகழ்வுக் கேட்பாளர்களை தனித்து (in isolation) எவ்வாறு சோதிப்பது?
• தரவுத்தளத்தில் சேமிப்பதற்கு முன்பா அல்லது பின்பா நான் டொமைன் நிகழ்வுகளை வெளிப்படுத்த வேண்டும்?
• டொமைன் நிகழ்விற்கும் வெப்ஹூக்கிற்கும் என்ன வித்தியாசம்?
• டொமைன் நிகழ்வுகளைப் பயன்படுத்தும் போது எவென்சுவல் கன்சிஸ்டென்ஸியை (eventual consistency) எவ்வாறு கையாள்வது?

டேக்ஸ்

#laravel #domainDrivenDesign #architecture #eventSourcing #PHP #cleanArchitecture #refactoring #scalability