Eloquent Events ವರ್ಸಸ್ Domain Events: Framework Hooks ಏಕೆ ಸಾಕಾಗುವುದಿಲ್ಲ

ನಿಮ್ಮ Eloquent listener ಪರಿಪೂರ್ಣವೆನಿಸಿತು: ಇದನ್ನು Order ಮಾಡೆಲ್‌ನ saved event ಗೆ ಸೇರಿಸಿ, ಆದೇಶವನ್ನು (order) ಉಳಿಸಿದಾಗ (saved) ದೃಢೀಕರಣ (confirmation) ಇಮೇಲ್ ಕಳುಹಿಸಿ, ಮತ್ತು ನಿಮ್ಮ ಕೆಲಸ ಮುಗಿಯಿತು. ಇದು ಡೆಮೊದಲ್ಲಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ. ನಂತರ ಪ್ರೊಡಕ್ಷನ್ (production) ಹಂತಕ್ಕೆ ಬರುತ್ತದೆ, ಮತ್ತು ಸಪೋರ್ಟ್ ಟಿಕೆಟ್ (support ticket) ಬರುತ್ತದೆ. ಒಬ್ಬ ಗ್ರಾಹಕರು ಒಂದೇ ಖರೀದಿಗೆ ಎರಡು ದೃಢೀಕರಣ ಇಮೇಲ್‌ಗಳನ್ನು ಪಡೆದರು. ಮತ್ತೊಬ್ಬರು ರದ್ದತಿ (cancellation) ಸೂಚನೆ ಇಲ್ಲದೆ ಮರುಪಾವತಿ (refund) ರಸೀದಿಯನ್ನು ಪಡೆದರು. ನೀವು ನಿಮ್ಮ ಲಾಗ್‌ಗಳನ್ನು (logs) ಪರಿಶೀಲಿಸುತ್ತೀರಿ ಮತ್ತು ಯಾವುದೇ ತಪ್ಪನ್ನು ಕಾಣುವುದಿಲ್ಲ. ಇಮೇಲ್‌ಗಳು ಹೋಗಿವೆ. ಕೋಡ್ (code) ಉತ್ತಮವಾಗಿದೆ. ಸಮಸ್ಯೆ ಸೂಕ್ಷ್ಮವಾಗಿದೆ, ಮತ್ತು ಇದು ನಿಮ್ಮ ಆರ್ಕಿಟೆಕ್ಚರ್‌ನಲ್ಲಿದೆ (architecture).

ಇಂದು ಇದು ಏಕೆ ಮುಖ್ಯವಾಗಿದೆ (ಜುಲೈ 2026)

2026 ರಲ್ಲಿ, ವಾರಾಂತ್ಯದ ಪ್ರಾಜೆಕ್ಟ್‌ಗೆ ಕೆಲಸ ಮಾಡುವ ಆದರೆ ಪ್ರೊಡಕ್ಷನ್‌ನಲ್ಲಿ ವಿಫಲವಾಗುವ ಕೋಡ್ ಮೊದಲಿಗಿಂತ ಹೆಚ್ಚು ದುಬಾರಿಯಾಗಿದೆ. ನಿಮ್ಮ ಅಪ್ಲಿಕೇಶನ್ ಸ್ಕೇಲ್ (scale) ಆಗಬೇಕೆಂದು ನಿಮ್ಮ ತಂಡ ನಿರೀಕ್ಷಿಸುತ್ತದೆ. ನಿಮ್ಮ ಗ್ರಾಹಕರು ವಿಶ್ವಾಸಾರ್ಹತೆಯನ್ನು (reliability) ನಿರೀಕ್ಷಿಸುತ್ತಾರೆ. Framework hook ಗಳು ಅನುಕೂಲಕರವಾಗಿವೆ, ಆದರೆ ಅನುಕೂಲವು ಹೆಚ್ಚಾಗಿ ನಿಯಂತ್ರಣದ (control) ವೆಚ್ಚದಲ್ಲಿ ಬರುತ್ತದೆ. ನಿಮ್ಮ ಅಪ್ಲಿಕೇಶನ್ ಪ್ರೂಫ್-ಆಫ್-ಕಾನ್ಸೆಪ್ಟ್‌ನಿಂದ (proof-of-concept) ಆಚೆಗೆ ಬೆಳೆದಂತೆ, ಇಮೇಲ್‌ಗಳನ್ನು ಕಳುಹಿಸುವಂತಹ ಸೈಡ್ ಎಫೆಕ್ಟ್‌ಗಳನ್ನು (side effects) ಹೇಗೆ ನಿಭಾಯಿಸಬೇಕು ಎಂಬುದರ ಕುರಿತು ನೀವು ತೆಗೆದುಕೊಳ್ಳುವ ನಿರ್ಧಾರಗಳು, ನಿಮ್ಮ ಅಪ್ಲಿಕೇಶನ್ ನಿರ್ವಹಿಸಬಲ್ಲ ಮಟ್ಟದಲ್ಲಿ (maintainable) ಇರುತ್ತದೆಯೇ ಅಥವಾ ಅಸ್ಪಷ್ಟ ಡಿಪೆಂಡೆನ್ಸಿಗಳ (implicit dependencies) ಚಕ್ರವ್ಯೂಹವಾಗುತ್ತದೆಯೇ ಎಂಬುದನ್ನು ನಿರ್ಧರಿಸುತ್ತವೆ.

Eloquent Events ನ ಆಕರ್ಷಣೆ

Eloquent event ಗಳು ಸುಲಭವಾದ ಬಟನ್ ಆಗಿವೆ. Laravel ನ ORM ನಿಮಗೆ lifecycle hook ಗಳನ್ನು ನೀಡುತ್ತದೆ: creating, created, updating, updated, saved, deleted. ನೀವು listener ಅನ್ನು ನೋಂದಾಯಿಸುತ್ತೀರಿ (register), ಮತ್ತು event ಸಂಭವಿಸಿದಾಗ ಅದು ಫೈರ್ ಆಗುತ್ತದೆ (fires). ಯಾವುದೇ ಕಾನ್ಫಿಗರೇಶನ್ (configuration) ಇಲ್ಲ, ಯಾವುದೇ ವಿಧಿವಿಧಾನಗಳಿಲ್ಲ.

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

ಮೇಲ್ನೋಟಕ್ಕೆ ಇದು ಕ್ಲೀನ್ ಕೋಡ್ (clean code) ಆಗಿದೆ. ಉದ್ದೇಶ ಸ್ಪಷ್ಟವಾಗಿದೆ: ಆರ್ಡರ್ (order) ಅನ್ನು ಸೇವ್ (saved) ಮಾಡಿದಾಗ, ಕನ್ಫರ್ಮೇಶನ್ (confirmation) ಕಳುಹಿಸಿ. ಇದು ಕೆಲಸ ಮಾಡುತ್ತದೆ. ಮತ್ತು ಸರಳವಾದ ಪ್ರಾಜೆಕ್ಟ್‌ಗೆ (project), ಅದು ಸಾಕು. ನೀವು ಬಹು (multiple) listener ಗಳನ್ನು ಹೊಂದಿರುವಾಗ, ಅಥವಾ ಒಂದೇ ಮಾಡೆಲ್ (model) ಅನ್ನು ಬೇರೆ ಬೇರೆ ಕಾರಣಗಳಿಗಾಗಿ ಸೇವ್ ಮಾಡಿದಾಗ ಸಮಸ್ಯೆ ಉದ್ಭವಿಸುತ್ತದೆ.

ಅಡಗಿರುವ ಸಮಸ್ಯೆ: ಉದ್ದೇಶ (Intent) ಮತ್ತು ಸನ್ನಿವೇಶ (Context)

ಇಲ್ಲಿಯೇ ವಿಷಯಗಳು ಮುರಿದುಬೀಳುತ್ತವೆ. Eloquent ನ saved event, ಆರ್ಡರ್ ಅನ್ನು (order) ಸೇವ್ ಮಾಡಿದಾಗಲೆಲ್ಲಾ ಫೈರ್ (fires) ಆಗುತ್ತದೆ, ಅದನ್ನು ಏಕೆ ಸೇವ್ ಮಾಡಲಾಗಿದೆ ಎಂಬುದನ್ನು ಲೆಕ್ಕಿಸದೆ. ಬಹುಶಃ ನೀವು ಅದನ್ನು ಕ್ರಿಯೇಟ್ (created) ಮಾಡಿರಬಹುದು. ಬಹುಶಃ ನೀವು ಸ್ಟೇಟಸ್ (status) ಅನ್ನು 'pending' ನಿಂದ 'confirmed' ಗೆ ಅಪ್‌ಡೇಟ್ (updated) ಮಾಡಿರಬಹುದು. ಬಹುಶಃ ನೀವು ಶಿಪ್ಪಿಂಗ್ (shipping) ವಿಳಾಸವನ್ನು ಅಪ್‌ಡೇಟ್ ಮಾಡಿರಬಹುದು. The saved event ಯಾವುದನ್ನೂ ಲೆಕ್ಕಿಸುವುದಿಲ್ಲ—ಅದು ಎಲ್ಲದಕ್ಕೂ ಫೈರ್ ಆಗುತ್ತದೆ.

ಈಗ ಈ ಸನ್ನಿವೇಶವನ್ನು ಊಹಿಸಿ. ರಿಫಂಡ್ ಫ್ಲೋ (refund flow) ಆರ್ಡರ್ (order) ಅನ್ನು ಹೀಗೆ ಸೇವ್ (saves) ಮಾಡುತ್ತದೆ refunded ಸ್ಟೇಟಸ್ (status). ಪ್ರತ್ಯೇಕ ಪ್ರಕ್ರಿಯೆ—ಬಹುಶಃ ಶೆಡ್ಯೂಲ್ಡ್ ಜಾಬ್ (scheduled job), ಬಹುಶಃ ನಿಮ್ಮ ಪೇಮೆಂಟ್ ಪ್ರೊಸೆಸರ್‌ನಿಂದ (payment processor) ವೆಬ್‌ಹುಕ್ (webhook)—ಸಹ ಆರ್ಡರ್ ಅನ್ನು ಅಪ್‌ಡೇಟ್ (updates) ಮಾಡುತ್ತದೆ. ಇವೆರಡೂ ಇದನ್ನು ಟ್ರಿಗರ್ (trigger) ಮಾಡುತ್ತವೆ saved event. ಎರಡು listener ಗಳು ರನ್ ಆಗುತ್ತವೆ. ಒಂದು ರಿಫಂಡ್ (refund) ಇಮೇಲ್ ಕಳುಹಿಸುತ್ತದೆ, ಇನ್ನೊಂದು ಬೇರೆ ನೋಟಿಫಿಕೇಶನ್ (notification) ಅನ್ನು ಕಳುಹಿಸುತ್ತದೆ. ಗ್ರಾಹಕರಿಗೆ ಎರಡೂ ಸಂದೇಶಗಳು ಬರುತ್ತವೆ, ಮತ್ತು ಯಾವುದು ನಿಜ ಎಂಬುದರ ಬಗ್ಗೆ ಅವರು ಗೊಂದಲಕ್ಕೊಳಗಾಗುತ್ತಾರೆ.

ಮೂಲ ಕಾರಣವೇನೆಂದರೆ Eloquent event ಗಳು ಡೇಟಾಬೇಸ್ ಕಾರ್ಯಾಚರಣೆಗೆ (database operation) ಸಂಬಂಧಿಸಿವೆಯೇ ಹೊರತು ಬಿಸಿನೆಸ್ ಆಕ್ಷನ್‌ಗೆ (business action) ಅಲ್ಲ. ನಿಮ್ಮ ಕೋಡ್ "an order was saved" ಎಂದು ಹೇಳುತ್ತದೆ, ಆದರೆ ನಿಮ್ಮ ನೈಜ ಅರ್ಥ "an order was created" ಅಥವಾ "a refund was issued" ಅಥವಾ "shipping details were updated." ಎಂಬುದಾಗಿರುತ್ತದೆ. ಇವು ವಿಭಿನ್ನ ಸೈಡ್ ಎಫೆಕ್ಟ್‌ಗಳೊಂದಿಗೆ (side effects) ವಿಭಿನ್ನ ಆಕ್ಷನ್‌ಗಳಾಗಿವೆ.

Framework Events ಸ್ಕೇಲ್ (Scale) ಆಗುವುದಿಲ್ಲ

ನಿಮ್ಮ ಅಪ್ಲಿಕೇಶನ್ ಬೆಳೆದಂತೆ, ಈ ಸಮಸ್ಯೆ ಉಲ್ಬಣಗೊಳ್ಳುತ್ತದೆ. ನೀವು ಹೊಸ listener ಅನ್ನು ಸೇರಿಸುತ್ತೀರಿ. ಅದು ಕೆಲಸ ಮಾಡುತ್ತದೆ. ನೀವು ಇನ್ನೊಂದನ್ನು ಸೇರಿಸುತ್ತೀರಿ. ಈಗ ನೀವು ಇದರಲ್ಲಿ ಐದು listener ಗಳನ್ನು ಹೊಂದಿದ್ದೀರಿ saved event, ಮತ್ತು ಪ್ರತಿಯೊಂದೂ ಏನು ಮಾಡುತ್ತದೆ ಎಂಬುದನ್ನು ನೀವು ನೆನಪಿಟ್ಟುಕೊಳ್ಳಲು ಸಾಧ್ಯವಿಲ್ಲ. ಬಗ್ (bug) ಕಾಣಿಸಿಕೊಂಡಾಗ, ಅದಕ್ಕೆ ಕಾರಣವಾದದ್ದು ಯಾವುದು ಎಂದು ಕಂಡುಹಿಡಿಯಲು ನೀವು ಐದನ್ನೂ ಟ್ರೇಸ್ (trace) ಮಾಡಬೇಕಾಗುತ್ತದೆ. ಡಿಪೆಂಡೆನ್ಸಿಗಳು (dependencies) ಅಸ್ಪಷ್ಟವಾಗಿರುತ್ತವೆ ಮತ್ತು ನಿಮ್ಮ ಕೋಡ್‌ಬೇಸ್‌ನಾದ್ಯಂತ (codebase) ಹರಡಿಕೊಂಡಿರುತ್ತವೆ.

ಇನ್ನೂ ಕೆಟ್ಟದ್ದೆಂದರೆ, ಎರಡು listener ಗಳು ಒಂದನ್ನೊಂದು ಅವಲಂಬಿಸಿದ್ದರೆ—ಒಂದು ಇನ್ನೊಂದರ ಮೊದಲು ರನ್ (run) ಆಗಬೇಕಿದ್ದರೆ—ಆ ಕ್ರಮವನ್ನು (order) ಜಾರಿಗೊಳಿಸಲು ನಿಮಗೆ ಯಾವುದೇ ಮಾರ್ಗವಿಲ್ಲ. Eloquent ಅವುಗಳನ್ನು ರಿಜಿಸ್ಟ್ರೇಶನ್ ಕ್ರಮದಲ್ಲಿ (registration order) ಫೈರ್ ಮಾಡುತ್ತದೆ, ಇದು ದುರ್ಬಲವಾಗಿದೆ (fragile). ಫೈಲ್‌ನ ತಪ್ಪು ಸ್ಥಳದಲ್ಲಿ ಯಾರಾದರೂ listener ಅನ್ನು ಸೇರಿಸಿದರೆ, ಸೈಡ್ ಎಫೆಕ್ಟ್‌ಗಳು (side effects) ತಪ್ಪು ಕ್ರಮದಲ್ಲಿ ಸಂಭವಿಸುತ್ತವೆ.

Domain Events: ಉದ್ದೇಶ (Intent) ಪ್ರಥಮ ದರ್ಜೆ (First-Class) ಆಗಿ

Domain event ಗಳು ಒಂದು ವಿಭಿನ್ನ ವಿಧಾನವಾಗಿದ್ದು, ಡೊಮೇನ್-ಡ್ರಿವನ್ ಡಿಸೈನ್ (domain-driven design - DDD) ನಿಂದ ಎರವಲು ಪಡೆಯಲಾಗಿದೆ. ಡೇಟಾಬೇಸ್ ಕಾರ್ಯಾಚರಣೆಗಳ (database operations) ಮೇಲೆ ಅವಲಂಬಿಸುವ ಬದಲು, ನಿಮ್ಮ ಬಿಸಿನೆಸ್ ಲಾಜಿಕ್‌ನಲ್ಲಿ (business logic) ವಾಸ್ತವವಾಗಿ ಏನಾಯಿತು ಎಂಬುದನ್ನು ಪ್ರತಿನಿಧಿಸುವ event ಗಳನ್ನು ನೀವು ಎಮಿಟ್ (emit) ಮಾಡುತ್ತೀರಿ.

ಇದರ ಬದಲಾಗಿ saved event, ನೀವು ಎಮಿಟ್ (emit) ಮಾಡುತ್ತೀರಿ OrderCreated event ಅಥವಾ OrderRefunded event. ಪ್ರತಿ event ಸನ್ನಿವೇಶವನ್ನು (context) ಹೊಂದಿರುತ್ತದೆ: ಏನಾಯಿತು ಮತ್ತು ಏಕೆ ಎಂದು. ನಂತರ ನಿಮ್ಮ listener ಗಳು ತಾವು ಕಾಳಜಿ ವಹಿಸುವ event ಗಳಿಗೆ ಸಬ್‌ಸ್ಕ್ರೈಬ್ (subscribe) ಆಗುತ್ತವೆ.

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

ಈಗ ನಿಮ್ಮ ಕನ್ಫರ್ಮೇಶನ್ (confirmation) ಇಮೇಲ್ listener ಇದಕ್ಕೆ ಮಾತ್ರ ಸಬ್‌ಸ್ಕ್ರೈಬ್ (subscribes) ಆಗುತ್ತದೆ OrderCreated, ಇದಕ್ಕಲ್ಲ OrderSaved. ರಿಫಂಡ್ (refund) ಇಮೇಲ್ ಇದಕ್ಕೆ ಮಾತ್ರ ಸಬ್‌ಸ್ಕ್ರೈಬ್ ಆಗುತ್ತದೆ OrderRefunded. ಪ್ರತಿಯೊಂದು ಸೈಡ್ ಎಫೆಕ್ಟ್ (side effect) ಅದು ಪ್ರತಿನಿಧಿಸುವ ಆಕ್ಷನ್‌ಗೆ (action) ಸಂಬಂಧಿಸಿರುತ್ತದೆಯೇ ಹೊರತು ಡೇಟಾಬೇಸ್ ಕಾರ್ಯಾಚರಣೆಗೆ (database operation) ಅಲ್ಲ.

ನಿಮ್ಮ ಸೈಡ್ ಎಫೆಕ್ಟ್‌ಗಳನ್ನು (Side Effects) ಡಿಕಪಲ್ (Decoupling) ಮಾಡುವುದು

Domain event ಗಳು ನಿಮ್ಮ ಡೊಮೇನ್ ಲಾಜಿಕ್ (domain logic) ಅನ್ನು ನಿಮ್ಮ ಫ್ರೇಮ್‌ವರ್ಕ್‌ನಿಂದ (framework) ಡಿಕಪಲ್ (decouple) ಮಾಡುತ್ತವೆ. Eloquent ನ saved event ಒಂದು Laravel ಪರಿಕಲ್ಪನೆ. Domain event ಗಳು ಹಾಗಲ್ಲ. ನಿಮ್ಮ ಬಿಸಿನೆಸ್ ಲಾಜಿಕ್ ಅನ್ನು ವಿಭಿನ್ನ ಫ್ರೇಮ್‌ವರ್ಕ್‌ಗೆ ಸರಿಸಲು ಅಥವಾ ಕನ್ಸೋಲ್ ಕಮಾಂಡ್‌ನಲ್ಲಿ (console command) ಬಳಸಲು ಅಥವಾ ಐಸೋಲೇಶನ್‌ನಲ್ಲಿ (isolation) ಟೆಸ್ಟ್ ಮಾಡಲು ನೀವು ಎಂದಾದರೂ ಬಯಸಿದರೆ, domain event ಗಳು ಅದನ್ನು ಸಾಧ್ಯವಾಗಿಸುತ್ತವೆ. Framework event ಗಳು ಅದನ್ನು ಕಷ್ಟಕರವಾಗಿಸುತ್ತವೆ.

domain event ಗಳೊಂದಿಗೆ, ನಿಮ್ಮ ಬಿಸಿನೆಸ್ ಲಾಜಿಕ್ ಆಕ್ಷನ್ ಕ್ಲಾಸ್‌ಗಳಲ್ಲಿ (action classes) ಅಥವಾ ಸೇವೆಗಳಲ್ಲಿ (services) ವಾಸಿಸುತ್ತದೆ, ORM ನಿಂದ ಸ್ವತಂತ್ರವಾಗಿ. ಫ್ರೇಮ್‌ವರ್ಕ್ ನೀವು ಬಳಸುವ ಸಾಧನವಾಗುತ್ತದೆ, ನಿಮ್ಮ ಲಾಜಿಕ್ ಅದರಲ್ಲಿ ಸಿಲುಕಿಕೊಳ್ಳುವುದಿಲ್ಲ.

ಒಂದು ಕಾಂಕ್ರೀಟ್ ಉದಾಹರಣೆ: ರಿಫಂಡ್ ಫ್ಲೋ (The Refund Flow)

ಒಂದು ರಿಫಂಡ್ (refund) ಪ್ರಕ್ರಿಯೆಯನ್ನು ಊಹಿಸಿ. ಆಗಬೇಕಾದ ಮೂರು ವಿಷಯಗಳು ನಿಮ್ಮ ಬಳಿ ಇವೆ: ಆರ್ಡರ್ ಸ್ಟೇಟಸ್ ಅನ್ನು ಅಪ್‌ಡೇಟ್ (update) ಮಾಡುವುದು, ನಿಮ್ಮ ಮರ್ಚೆಂಟ್ ಖಾತೆಯಿಂದ (merchant account) ಹಣವನ್ನು ಕಡಿತಗೊಳಿಸುವುದು ಮತ್ತು ಗ್ರಾಹಕರಿಗೆ ರಿಫಂಡ್ ಇಮೇಲ್ ಕಳುಹಿಸುವುದು.

Eloquent event ಗಳೊಂದಿಗೆ, ನೀವು listener ಗಳನ್ನು ವೈರ್ (wire) ಮಾಡುತ್ತೀರಿ saved event ಗೆ. ಆದರೆ ಅದು ಅಚ್ಚುಕಟ್ಟಾಗಿರುವುದಿಲ್ಲ (sloppy). ಮರ್ಚೆಂಟ್ ಅಕೌಂಟ್ (merchant account) ಕಡಿತಕ್ಕೂ, ಆರ್ಡರ್ ಸೇವ್ ಆಗುವುದಕ್ಕೂ ಯಾವುದೇ ಸಂಬಂಧವಿಲ್ಲ. ರಿಫಂಡ್ ಅನ್ನು (refund) ಇನಿಶಿಯೇಟ್ (initiated) ಮಾಡಿದಾಗ ಅದು ಸಂಭವಿಸಬೇಕು.

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

ಈಗ ನೀವು ಲಿಸನ್ (listen) ಮಾಡಬಹುದು OrderRefunded ಮತ್ತು ಪ್ರತಿಯೊಂದು ವಿಷಯವನ್ನು ಪ್ರತ್ಯೇಕವಾಗಿ ನಿಭಾಯಿಸಿ. ಮರ್ಚೆಂಟ್ ಅಕೌಂಟ್ (merchant account) ಕಡಿತ, ಇಮೇಲ್, ಅಕೌಂಟಿಂಗ್ ಲೆಡ್ಜರ್ ಎಂಟ್ರಿ (accounting ledger entry)—ಪ್ರತಿ listener ಒಂದೊಂದು ವಿಷಯವನ್ನು ನಿಭಾಯಿಸುತ್ತದೆ.

ಟ್ರಾನ್ಸಿಶನ್ (Transition) ಮಾರ್ಗ

ನೀವು ಇಂದು ನಿಮ್ಮ ಎಲ್ಲಾ Eloquent listener ಗಳನ್ನು ಕಿತ್ತುಹಾಕಬೇಕಾಗಿಲ್ಲ. ಟ್ರಾನ್ಸಿಶನ್ (transition) ಹಂತಹಂತವಾಗಿರಬಹುದು. ನಿಮ್ಮ ಆಕ್ಷನ್ ಕ್ಲಾಸ್‌ಗಳಿಂದ (action classes) ಡೊಮೇನ್ ಇವೆಂಟ್‌ಗಳನ್ನು (domain events) ಎಮಿಟ್ (emit) ಮಾಡಲು ಪ್ರಾರಂಭಿಸಿ. ಕಾಲಾನಂತರದಲ್ಲಿ, listener ಗಳನ್ನು ಸರಿಸಿ. ನೀವು ಅವುಗಳನ್ನು ಬದಲಾಯಿಸಿದಂತೆ Eloquent listener ಗಳನ್ನು ಅಳಿಸಿ (Delete).

ತೀರ್ಮಾನ (Conclusion)

Framework event hook ಗಳು ಅನುಕೂಲಕರವಾಗಿವೆ, ಆದರೆ ನಿಮ್ಮ ಕೋಡ್ ಬೆಳೆದಂತೆ ಅವು ಸ್ಪಷ್ಟತೆ (clarity) ಮತ್ತು ನಿರ್ವಹಣಾ ಸಾಮರ್ಥ್ಯವನ್ನು (maintainability) ಕಳೆದುಕೊಳ್ಳುವ ಶಾರ್ಟ್‌ಕಟ್ (shortcut) ಆಗಿವೆ. Domain event ಗಳಿಗೆ ಮುಂಚಿತವಾಗಿ ಸ್ವಲ್ಪ ಹೆಚ್ಚು ಯೋಚಿಸಬೇಕಾಗುತ್ತದೆ, ಆದರೆ ಅವು ಸ್ಕೇಲ್ (scale) ಆಗುತ್ತವೆ. ಏನಾಗುತ್ತಿದೆ ಮತ್ತು ಏಕೆ ಎಂಬುದರ ಕುರಿತು ಅವು ಸ್ಪಷ್ಟವಾಗಿವೆ. ಅವು ನಿಮ್ಮ ಬಿಸಿನೆಸ್ ಲಾಜಿಕ್ ಅನ್ನು ನಿಮ್ಮ ಫ್ರೇಮ್‌ವರ್ಕ್‌ನಿಂದ ಡಿಕಪಲ್ (decouple) ಮಾಡುತ್ತವೆ. ಬಗ್ (bug) ಕಾಣಿಸಿಕೊಂಡಾಗ, ಎಲ್ಲಿ ನೋಡಬೇಕು ಎಂಬುದು ನಿಮಗೆ ನಿಖರವಾಗಿ ತಿಳಿದಿರುತ್ತದೆ.

ಅನುಕೂಲಗಳು (Merits)

• ಇವೆಂಟ್‌ಗಳು ವಾಸ್ತವಿಕ ಬಿಸಿನೆಸ್ ಆಕ್ಷನ್‌ಗಳನ್ನು ಪ್ರತಿನಿಧಿಸುತ್ತವೆ, ಡೇಟಾಬೇಸ್ ಕಾರ್ಯಾಚರಣೆಗಳನ್ನಲ್ಲ (database operations)
• ಯಾವ ಆಕ್ಷನ್‌ಗಳಿಗೆ ಯಾವ ಸೈಡ್ ಎಫೆಕ್ಟ್‌ಗಳು (side effects) ಟ್ರಿಗರ್ (trigger) ಆಗುತ್ತವೆ ಎಂಬುದನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳುವುದು ಸುಲಭ
• listener ಗಳ ನಡುವೆ ಯಾವುದೇ ಗುಪ್ತ ಡಿಪೆಂಡೆನ್ಸಿಗಳಿಲ್ಲ (dependencies)
• ಫ್ರೇಮ್‌ವರ್ಕ್-ಅಗ್ನಾಸ್ಟಿಕ್ (Framework-agnostic)—ನಿಮ್ಮ ಬಿಸಿನೆಸ್ ಲಾಜಿಕ್ Laravel ಗೆ ಕಟ್ಟಲ್ಪಟ್ಟಿಲ್ಲ
• ಫ್ರೇಮ್‌ವರ್ಕ್ ಸೆಟಪ್ (framework setup) ಇಲ್ಲದೆ ಐಸೋಲೇಶನ್‌ನಲ್ಲಿ (isolation) ಟೆಸ್ಟ್ ಮಾಡಬಹುದು
• listener ಗಳನ್ನು ಉದ್ದೇಶಪೂರ್ವಕವಾಗಿ ಆರ್ಡರ್ (ordered) ಮಾಡಬಹುದು ಮತ್ತು ಸಂಘಟಿಸಬಹುದು (coordinated)

ಅನಾನುಕೂಲಗಳು (Demerits)

• framework listener ಗಳಿಗಿಂತ ಹೆಚ್ಚಿನ ಬಾಯ್ಲರ್‌ಪ್ಲೇಟ್ (boilerplate) ಅಗತ್ಯವಿದೆ
• event ಗಳನ್ನು ಮ್ಯಾನ್ಯುವಲ್ (manually) ಆಗಿ ಎಮಿಟ್ (emit) ಮಾಡಬೇಕಾಗುತ್ತದೆ; ಸ್ವಯಂಚಾಲಿತವಾಗಿ ಸಂಭವಿಸುವುದಿಲ್ಲ
• ಡೆವಲಪ್‌ಮೆಂಟ್ (development) ಸಮಯದಲ್ಲಿ ಹೆಚ್ಚಿನ ಮಾನಸಿಕ ಓವರ್‌ಹೆಡ್ (mental overhead)
• ಶಿಸ್ತಿನ (discipline) ಅಗತ್ಯವಿದೆ—event ಅನ್ನು ಎಮಿಟ್ (emit) ಮಾಡಲು ಮರೆಯುವುದು ಸುಲಭ
• event ಗಳನ್ನು ಲಾಗ್ (logged) ಮಾಡದಿದ್ದರೆ ಡಿಬಗ್ಗಿಂಗ್ (debugging) ಸ್ವಲ್ಪ ಕಷ್ಟವಾಗುತ್ತದೆ

ಎಚ್ಚರಿಕೆ (Caution)

ಈ ಲೇಖನದಲ್ಲಿನ ಉದಾಹರಣೆ ಕೋಡ್ ಮತ್ತು ಪ್ಯಾಟರ್ನ್ ಹೆಸರುಗಳು (pattern names) ಜೆನೆರಿಕ್ (generic) ವಿವರಣೆಗಳಾಗಿವೆ, ನಿರ್ದಿಷ್ಟ ಪ್ರೊಡಕ್ಷನ್ (production) ಕೋಡ್ ಅಲ್ಲ. ಪ್ರೊಡಕ್ಷನ್‌ಗೆ ಡೆಪ್ಲಾಯ್ (deploying) ಮಾಡುವ ಮೊದಲು ನಿಮ್ಮ event ಫ್ಲೋ ಅನ್ನು ಸಂಪೂರ್ಣವಾಗಿ ಟೆಸ್ಟ್ ಮಾಡಿ. ನಿಮ್ಮ ಸ್ವಂತ ಅಪಾಯದಲ್ಲಿ ಮುಂದುವರಿಯಿರಿ. ನೀವು ಪ್ರಸ್ತುತ Eloquent event ಗಳನ್ನು ಬಳಸುತ್ತಿದ್ದರೆ, domain event ಗಳಿಗೆ ಮೈಗ್ರೇಟ್ ಮಾಡುವುದು (migrating) ಒಂದು ರಿಫ್ಯಾಕ್ಟರಿಂಗ್ (refactoring) ಕಾರ್ಯವಾಗಿದ್ದು, ನಿಮ್ಮ ಸೈಡ್ ಎಫೆಕ್ಟ್‌ಗಳಿಗೆ (side effects) ಉತ್ತಮ ಟೆಸ್ಟ್ ಕವರೇಜ್‌ನೊಂದಿಗೆ (test coverage) ಎಚ್ಚರಿಕೆಯಿಂದ ಮಾಡಬೇಕು.

ಪದೇ ಪದೇ ಕೇಳಲಾಗುವ ಪ್ರಶ್ನೆಗಳು (Frequently asked questions)

• ಒಂದೇ ಆಕ್ಷನ್‌ಗೆ (action) ಪ್ರತಿಕ್ರಿಯಿಸಬೇಕಾದ ಬಹು (multiple) ಡೊಮೇನ್‌ಗಳನ್ನು ನಾನು ಹೊಂದಿದ್ದರೆ ಏನು ಮಾಡುವುದು?
• listener ಗಳ ನಡುವಿನ ಇವೆಂಟ್ ಆರ್ಡರಿಂಗ್ (event ordering) ಮತ್ತು ಡಿಪೆಂಡೆನ್ಸಿಗಳನ್ನು (dependencies) ನಾನು ಹೇಗೆ ನಿಭಾಯಿಸುವುದು?
• ನಾನು Eloquent ನೊಂದಿಗೆ domain event ಗಳನ್ನು ಬಳಸಬಹುದೇ ಅಥವಾ ನನಗೆ ಬೇರೆ ORM ಅಗತ್ಯವಿದೆಯೇ?
• event listener ವಿಫಲವಾದರೆ ಏನಾಗುತ್ತದೆ—ಸಂಪೂರ್ಣ ಟ್ರಾನ್ಸಾಕ್ಷನ್ (transaction) ರೋಲ್‌ಬ್ಯಾಕ್ (rollback) ಆಗುತ್ತದೆಯೇ?
• ಐಸೋಲೇಶನ್‌ನಲ್ಲಿ (isolation) domain event listener ಗಳನ್ನು ನಾನು ಹೇಗೆ ಟೆಸ್ಟ್ ಮಾಡುವುದು?
• ಡೇಟಾಬೇಸ್‌ಗೆ ಸೇವ್ (saving) ಮಾಡುವ ಮೊದಲು ಅಥವಾ ನಂತರ ನಾನು domain event ಗಳನ್ನು ಎಮಿಟ್ (emit) ಮಾಡಬೇಕೆ?
• domain event ಮತ್ತು ವೆಬ್‌ಹುಕ್ (webhook) ನಡುವಿನ ವ್ಯತ್ಯಾಸವೇನು?
• domain event ಗಳನ್ನು ಬಳಸುವಾಗ ನಾನು ಇವೆಂಚ್ಯುಯಲ್ ಕನ್ಸಿಸ್ಟೆನ್ಸಿಯನ್ನು (eventual consistency) ಹೇಗೆ ನಿಭಾಯಿಸುವುದು?

ಟ್ಯಾಗ್‌ಗಳು (Tags)

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