Eloquent Events vs Domain Events: ଫ୍ରେମୱାର୍କ ହୁକ୍ସ କାହିଁକି ଯଥେଷ୍ଟ ନୁହେଁ

ଆପଣଙ୍କର Eloquent ଲିସେନର୍ ଉପଯୁକ୍ତ ଲାଗୁଥିଲା: ଏହାକୁ Order ମଡେଲର ସହିତ ଯୋଡ଼ନ୍ତୁ saved ଇଭେଣ୍ଟ, ଏକ ଅର୍ଡର ସେଭ୍ ହେବା ପରେ ଏକ କନଫର୍ମେସନ୍ ଇମେଲ୍ ପଠାନ୍ତୁ, ଏବଂ ଆପଣଙ୍କର କାମ ଶେଷ। ଏହା ଡେମୋରେ କାମ କରେ। ତା'ପରେ ପ୍ରଡକ୍ସନ୍ ଆରମ୍ଭ ହୁଏ, ଏବଂ ଏକ ସପୋର୍ଟ ଟିକେଟ୍ ଆସେ। ଜଣେ ଗ୍ରାହକ ଗୋଟିଏ କ୍ରୟ ପାଇଁ ଦୁଇଟି କନଫର୍ମେସନ୍ ଇମେଲ୍ ପାଇଲେ। ଅନ୍ୟ ଜଣେ ବିନା ବାତିଲ୍ ନୋଟିସରେ ରିଫଣ୍ଡ୍ ରସିଦ ପାଇଲେ। ଆପଣ ଆପଣଙ୍କର ଲଗ୍ସ ଯାଞ୍ଚ କରନ୍ତି ଏବଂ କିଛି ଭୁଲ୍ ପାଆନ୍ତି ନାହିଁ। ଇମେଲ୍ ଗୁଡ଼ିକ ଯାଇଥିଲା। କୋଡ୍ ଠିକ୍ ଲାଗୁଛି। ସମସ୍ୟାଟି ସୂକ୍ଷ୍ମ ଅଟେ, ଏବଂ ଏହା ଆପଣଙ୍କର ଆର୍କିଟେକ୍ଚରରେ ରହିଛି।

ଆଜି ଏହା କାହିଁକି ଗୁରୁତ୍ୱପୂର୍ଣ୍ଣ (ଜୁଲାଇ ୨୦୨୬)

୨୦୨୬ ମସିହାରେ, ଯେଉଁ କୋଡ୍ ଏକ ୱିକେଣ୍ଡ୍ ପ୍ରୋଜେକ୍ଟ ପାଇଁ କାମ କରେ କିନ୍ତୁ ପ୍ରଡକ୍ସନରେ ବିଫଳ ହୁଏ, ତାହା ପୂର୍ବ ଅପେକ୍ଷା ଅଧିକ ମହଙ୍ଗା ଅଟେ। ଆପଣଙ୍କର ଟିମ୍ ଆଶା କରେ ଯେ ଆପ୍ ସ୍କେଲ୍ କରିବ। ଆପଣଙ୍କର ଗ୍ରାହକମାନେ ନିର୍ଭରଯୋଗ୍ୟତା ଆଶା କରନ୍ତି। ଫ୍ରେମୱାର୍କ ହୁକ୍ସ ସୁବିଧାଜନକ, କିନ୍ତୁ ସୁବିଧା ପ୍ରାୟତଃ ନିୟନ୍ତ୍ରଣ ବଦଳରେ ଆସିଥାଏ। ଆପଣଙ୍କର ଆପ୍ଲିକେସନ୍ ଏକ ପ୍ରୁଫ୍-ଅଫ୍-କନସେପ୍ଟ ଠାରୁ ବଢିବା ସହିତ, ଆପଣ ସାଇଡ୍ ଇଫେକ୍ଟଗୁଡ଼ିକୁ କିପରି ପରିଚାଳନା କରିବେ—ଯେପରିକି ଇମେଲ୍ ପଠାଇବା—ତାହା ଉପରେ ଆପଣ ନେଉଥିବା ନିଷ୍ପତ୍ତିଗୁଡ଼ିକ ନିର୍ଦ୍ଧାରଣ କରେ ଯେ ଆପଣଙ୍କର ଆପ୍ ମେଣ୍ଟେନେବଲ୍ ରହିବ ନା ଅସ୍ପଷ୍ଟ ନିର୍ଭରଶୀଳତାର ଏକ ଜାଲ ପାଲଟିଯିବ।

Eloquent ଇଭେଣ୍ଟସର ଆକର୍ଷଣ

Eloquent ଇଭେଣ୍ଟସ୍ ହେଉଛି ସହଜ ବଟନ୍। ଲାରାଭେଲର (Laravel) ORM ଆପଣଙ୍କୁ ଲାଇଫସାଇକେଲ୍ ହୁକ୍ସ ପ୍ରଦାନ କରେ: creating, created, updating, updated, saved, deleted. ଆପଣ ଏକ ଲିସେନର୍ ରେଜିଷ୍ଟର କରନ୍ତି, ଏବଂ ଯେତେବେଳେ ଇଭେଣ୍ଟ ଘଟେ ଏହା ଫାୟାର୍ ହୁଏ। କୌଣସି କନଫିଗରେସନ୍ ନାହିଁ, କୌଣସି ଆନୁଷ୍ଠାନିକତା ନାହିଁ।

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

ଉପରୁ ଦେଖିଲେ ଏହା କ୍ଲିନ୍ କୋଡ୍ ଅଟେ। ଉଦ୍ଦେଶ୍ୟ ସ୍ପଷ୍ଟ: ଯେତେବେଳେ ଏକ ଅର୍ଡର ସେଭ୍ ହୁଏ, ଏକ କନଫର୍ମେସନ୍ ପଠାନ୍ତୁ। ଏହା କାମ କରେ। ଏବଂ ଏକ ସାଧାରଣ ପ୍ରୋଜେକ୍ଟ ପାଇଁ, ତାହା ଯଥେଷ୍ଟ। ସମସ୍ୟା ସେତେବେଳେ ଉପୁଜେ ଯେତେବେଳେ ଆପଣଙ୍କ ପାଖରେ ଏକାଧିକ ଲିସେନର୍ ଥାଏ, କିମ୍ବା ଯେତେବେଳେ ଏକା ମଡେଲ୍ ବିଭିନ୍ନ କାରଣରୁ ସେଭ୍ ହୁଏ।

ଲୁକ୍କାୟିତ ସମସ୍ୟା: ଉଦ୍ଦେଶ୍ୟ ଏବଂ ପ୍ରସଙ୍ଗ

ଏଠାରେ ଜିନିଷଗୁଡ଼ିକ ବିଗିଡିଯାଏ। ଇଲୋକ୍ୱେଣ୍ଟର (Eloquent's) saved ଯେତେବେଳେ ବି ଏକ ଅର୍ଡର ସେଭ୍ ହୁଏ, ଇଭେଣ୍ଟ ଫାୟାର୍ ହୁଏ, ଏହା କାହିଁକି ସେଭ୍ ହେଲା ତାହା ନିର୍ବିଶେଷରେ। ହୁଏତ ଆପଣ ଏହାକୁ କ୍ରିଏଟ୍ କରିଛନ୍ତି। ହୁଏତ ଆପଣ ଷ୍ଟାଟସ୍ କୁ 'pending' ରୁ 'confirmed' କୁ ଅପଡେଟ୍ କରିଛନ୍ତି। ହୁଏତ ଆପଣ ସିପିଂ ଠିକଣା ଅପଡେଟ୍ କରିଛନ୍ତି। ତାହା saved ଇଭେଣ୍ଟ ଖାତିର କରେ ନାହିଁ—ଏହା ସବୁବେଳେ ସମାନ ଭାବରେ ଫାୟାର୍ ହୁଏ।

ବର୍ତ୍ତମାନ ଏହି ପରିସ୍ଥିତି କଳ୍ପନା କରନ୍ତୁ। ଏକ ରିଫଣ୍ଡ୍ ଫ୍ଲୋ ଅର୍ଡରକୁ ଏକ ସହିତ ସେଭ୍ କରେ refunded ଷ୍ଟାଟସ୍। ଏକ ପୃଥକ୍ ପ୍ରକ୍ରିୟା—ହୁଏତ ଏକ ସିଡ୍ୟୁଲ୍ଡ୍ ଜବ୍, ହୁଏତ ଆପଣଙ୍କ ପେମେଣ୍ଟ ପ୍ରୋସେସରରୁ ଏକ ୱେବହୁକ୍—ମଧ୍ୟ ଅର୍ଡରକୁ ଅପଡେଟ୍ କରେ। ଉଭୟ ଟ୍ରିଗର୍ କରନ୍ତି saved ଇଭେଣ୍ଟ। ଦୁଇଟି ଲିସେନର୍ ରନ୍ କରନ୍ତି। ଗୋଟିଏ ଏକ ରିଫଣ୍ଡ୍ ଇମେଲ୍ ପଠାଏ, ଅନ୍ୟଟି ଏକ ଭିନ୍ନ ନୋଟିଫିକେସନ୍ ପଠାଏ। ଗ୍ରାହକ ଉଭୟ ମେସେଜ୍ ପାଆନ୍ତି, ଏବଂ କେଉଁଟି ପ୍ରକୃତ ତାହା ନେଇ ସେମାନେ ଦ୍ୱନ୍ଦ୍ୱରେ ପଡ଼ନ୍ତି।

ମୂଳ କାରଣ ହେଉଛି Eloquent ଇଭେଣ୍ଟଗୁଡ଼ିକ ଡାଟାବେସ୍ ଅପରେସନ୍ ସହିତ ଜଡିତ, ବିଜନେସ୍ ଆକ୍ସନ୍ ସହିତ ନୁହେଁ। ଆପଣଙ୍କର କୋଡ୍ କହୁଛି "ଏକ ଅର୍ଡର ସେଭ୍ କରାଯାଇଥିଲା," କିନ୍ତୁ ଆପଣ ପ୍ରକୃତରେ ଯାହା କହିବାକୁ ଚାହୁଁଛନ୍ତି ତାହା ହେଉଛି "ଏକ ଅର୍ଡର କ୍ରିଏଟ୍ କରାଯାଇଥିଲା" କିମ୍ବା "ଏକ ରିଫଣ୍ଡ୍ ଇସ୍ୟୁ କରାଯାଇଥିଲା" କିମ୍ବା "ସିପିଂ ବିବରଣୀ ଅପଡେଟ୍ କରାଯାଇଥିଲା।" ଏଗୁଡ଼ିକ ହେଉଛି ଭିନ୍ନ ସାଇଡ୍ ଇଫେକ୍ଟ ସହିତ ଭିନ୍ନ ଆକ୍ସନ୍।

ଫ୍ରେମୱାର୍କ ଇଭେଣ୍ଟଗୁଡ଼ିକ ସ୍କେଲ୍ କରେ ନାହିଁ

ଆପଣଙ୍କର ଆପ୍ଲିକେସନ୍ ବଢିବା ସହିତ, ଏହି ସମସ୍ୟା ବଢିଯାଏ। ଆପଣ ଏକ ନୂଆ ଲିସେନର୍ ଯୋଡ଼ନ୍ତି। ଏହା କାମ କରେ। ଆପଣ ଆଉ ଗୋଟିଏ ଯୋଡ଼ନ୍ତି। ବର୍ତ୍ତମାନ ଆପଣଙ୍କ ପାଖରେ ପାଞ୍ଚଟି ଲିସେନର୍ ଅଛି ଉପରେ saved ଇଭେଣ୍ଟ, ଏବଂ ପ୍ରତ୍ୟେକଟି କ'ଣ କରେ ତାହା ଆପଣ ମନେ ରଖିପାରିବେ ନାହିଁ। ଯେତେବେଳେ ଏକ ବଗ୍ ଦେଖାଦିଏ, କେଉଁଟି ଏହା ସୃଷ୍ଟି କଲା ତାହା ଜାଣିବା ପାଇଁ ଆପଣଙ୍କୁ ସମସ୍ତ ପାଞ୍ଚଟି ମାଧ୍ୟମରେ ଟ୍ରେସ୍ କରିବାକୁ ପଡିବ। ନିର୍ଭରଶୀଳତାଗୁଡ଼ିକ ଅସ୍ପଷ୍ଟ ଏବଂ ଆପଣଙ୍କ କୋଡବେସରେ ବିଛାଇ ହୋଇ ରହିଥାଏ।

ଆହୁରି ଖରାପ, ଯଦି ଦୁଇଟି ଲିସେନର୍ ପରସ୍ପର ଉପରେ ନିର୍ଭର କରନ୍ତି—ଗୋଟିଏ ଅନ୍ୟଟି ପୂର୍ବରୁ ରନ୍ କରିବା ଆବଶ୍ୟକ—ସେହି କ୍ରମକୁ ଲାଗୁ କରିବାକୁ ଆପଣଙ୍କ ପାଖରେ କୌଣସି ଉପାୟ ନାହିଁ। Eloquent ସେମାନଙ୍କୁ ରେଜିଷ୍ଟ୍ରେସନ୍ କ୍ରମରେ ଫାୟାର୍ କରେ, ଯାହା ଭଙ୍ଗୁର ଅଟେ। ଯଦି କେହି ଫାଇଲର ଭୁଲ୍ ସ୍ଥାନରେ ଏକ ଲିସେନର୍ ଯୋଡ଼ନ୍ତି, ତେବେ ସାଇଡ୍ ଇଫେକ୍ଟଗୁଡ଼ିକ ଭୁଲ୍ କ୍ରମରେ ଘଟେ।

ଡୋମେନ୍ ଇଭେଣ୍ଟସ୍: ଇଣ୍ଟେଣ୍ଟ ଆଜ୍ ଫାର୍ଷ୍ଟ-କ୍ଲାସ୍

ଡୋମେନ୍ ଇଭେଣ୍ଟସ୍ ହେଉଛି ଏକ ଭିନ୍ନ ଆଭିମୁଖ୍ୟ, ଯାହା ଡୋମେନ୍-ଡ୍ରିଭେନ୍ ଡିଜାଇନ୍ (DDD) ରୁ ଅଣାଯାଇଛି। ଡାଟାବେସ୍ ଅପରେସନ୍ ଉପରେ ନିର୍ଭର କରିବା ପରିବର୍ତ୍ତେ, ଆପଣ ଆପଣଙ୍କର ବିଜନେସ୍ ଲଜିକରେ ପ୍ରକୃତରେ କ'ଣ ଘଟିଲା ତାହା ଦର୍ଶାଉଥିବା ଇଭେଣ୍ଟଗୁଡ଼ିକୁ ଏମିଟ୍ କରନ୍ତି।

ବଦଳରେ saved ଇଭେଣ୍ଟ, ଆପଣ ଏକ ଏମିଟ୍ କରିବେ OrderCreated ଇଭେଣ୍ଟ କିମ୍ବା ଏକ OrderRefunded ଇଭେଣ୍ଟ। ପ୍ରତ୍ୟେକ ଇଭେଣ୍ଟ ପ୍ରସଙ୍ଗ ବହନ କରେ: କ'ଣ ଘଟିଲା, ଏବଂ କାହିଁକି। ତା'ପରେ ଆପଣଙ୍କର ଲିସେନର୍ସ ସେମାନଙ୍କର ଆବଶ୍ୟକ ଇଭେଣ୍ଟଗୁଡ଼ିକୁ ସବସ୍କ୍ରାଇବ୍ କରନ୍ତି।

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

ବର୍ତ୍ତମାନ ଆପଣଙ୍କର କନଫର୍ମେସନ୍ ଇମେଲ୍ ଲିସେନର୍ କେବଳ ସବସ୍କ୍ରାଇବ୍ କରେ OrderCreated, ନୁହେଁ OrderSaved। ରିଫଣ୍ଡ୍ ଇମେଲ୍ କେବଳ ସବସ୍କ୍ରାଇବ୍ କରେ OrderRefunded। ପ୍ରତ୍ୟେକ ସାଇଡ୍ ଇଫେକ୍ଟ ତାହା ପ୍ରତିନିଧିତ୍ୱ କରୁଥିବା ଆକ୍ସନ୍ ସହିତ ଜଡିତ, ଡାଟାବେସ୍ ଅପରେସନ୍ ସହିତ ନୁହେଁ।

ଆପଣଙ୍କର ସାଇଡ୍ ଇଫେକ୍ଟଗୁଡ଼ିକୁ ଡିକପଲ୍ କରିବା

ଡୋମେନ୍ ଇଭେଣ୍ଟସ୍ ମଧ୍ୟ ଆପଣଙ୍କର ଡୋମେନ୍ ଲଜିକକୁ ଆପଣଙ୍କ ଫ୍ରେମୱାର୍କରୁ ଡିକପଲ୍ କରେ। ଇଲୋକ୍ୱେଣ୍ଟର saved ଇଭେଣ୍ଟ ହେଉଛି ଏକ Laravel କନସେପ୍ଟ। ଡୋମେନ୍ ଇଭେଣ୍ଟସ୍ ନୁହେଁ। ଯଦି ଆପଣ କେବେ ଆପଣଙ୍କର ବିଜନେସ୍ ଲଜିକକୁ ଏକ ଭିନ୍ନ ଫ୍ରେମୱାର୍କକୁ ସ୍ଥାନାନ୍ତର କରିବାକୁ ଚାହାଁନ୍ତି, କିମ୍ବା ଏହାକୁ ଏକ କନସୋଲ୍ କମାଣ୍ଡରେ ବ୍ୟବହାର କରିବାକୁ ଚାହାଁନ୍ତି, କିମ୍ବା ଏହାକୁ ପୃଥକ୍ ଭାବରେ ଟେଷ୍ଟ୍ କରିବାକୁ ଚାହାଁନ୍ତି, ଡୋମେନ୍ ଇଭେଣ୍ଟସ୍ ତାହା ସମ୍ଭବ କରେ। ଫ୍ରେମୱାର୍କ ଇଭେଣ୍ଟସ୍ ଏହାକୁ କଷ୍ଟକର କରେ।

ଡୋମେନ୍ ଇଭେଣ୍ଟସ୍ ସହିତ, ଆପଣଙ୍କର ବିଜନେସ୍ ଲଜିକ୍ ଆକ୍ସନ୍ କ୍ଲାସ୍ କିମ୍ବା ସର୍ଭିସରେ ରହେ, ORM ଠାରୁ ସ୍ୱାଧୀନ ଭାବରେ। ଫ୍ରେମୱାର୍କ ଏକ ଟୁଲ୍ ପାଲଟିଯାଏ ଯାହାକୁ ଆପଣ ବ୍ୟବହାର କରନ୍ତି, ଏପରି କିଛି ନୁହେଁ ଯାହା ସହିତ ଆପଣଙ୍କ ଲଜିକ୍ ଜଡିତ ହୋଇ ରହିଥାଏ।

ଏକ ଠୋସ୍ ଉଦାହରଣ: ରିଫଣ୍ଡ୍ ଫ୍ଲୋ

ଏକ ରିଫଣ୍ଡ୍ ପ୍ରକ୍ରିୟା କଳ୍ପନା କରନ୍ତୁ। ଆପଣଙ୍କୁ ତିନୋଟି ଜିନିଷ କରିବାକୁ ପଡିବ: ଅର୍ଡର ଷ୍ଟାଟସ୍ ଅପଡେଟ୍ କରନ୍ତୁ, ଆପଣଙ୍କର ମର୍ଚାଣ୍ଟ୍ ଆକାଉଣ୍ଟରୁ ଟଙ୍କା କାଟନ୍ତୁ, ଏବଂ ଗ୍ରାହକଙ୍କୁ ଏକ ରିଫଣ୍ଡ୍ ଇମେଲ୍ ପଠାନ୍ତୁ।

Eloquent ଇଭେଣ୍ଟସ୍ ସହିତ, ଆପଣ ଲିସେନର୍ସ କୁ ଯୋଡ଼ିବେ saved ଇଭେଣ୍ଟ ସହିତ। କିନ୍ତୁ ତାହା ଅବ୍ୟବସ୍ଥିତ ଅଟେ। ମର୍ଚାଣ୍ଟ ଆକାଉଣ୍ଟ ଡିଡକ୍ସନ୍ ସହିତ ଅର୍ଡର ସେଭ୍ ହେବାର କୌଣସି ସମ୍ପର୍କ ନାହିଁ। ଏହା ସେତେବେଳେ ଘଟିବା ଉଚିତ୍ ଯେତେବେଳେ ଏକ ରିଫଣ୍ଡ୍ ଆରମ୍ଭ କରାଯାଏ।

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

ବର୍ତ୍ତମାନ ଆପଣ ଶୁଣିପାରିବେ OrderRefunded ଏବଂ ପ୍ରତ୍ୟେକ ବିଷୟକୁ ଅଲଗା ଅଲଗା ନିୟନ୍ତ୍ରଣ କରିପାରିବେ। ମର୍ଚାଣ୍ଟ ଆକାଉଣ୍ଟ ଡିଡକ୍ସନ୍, ଇମେଲ୍, ଆକାଉଣ୍ଟିଂ ଲେଜର ଏଣ୍ଟ୍ରି—ପ୍ରତ୍ୟେକ ଲିସେନର୍ ଗୋଟିଏ ଜିନିଷକୁ ହ୍ୟାଣ୍ଡେଲ କରେ।

ଟ୍ରାଞ୍ଜିସନ୍ ପଥ

ଆପଣଙ୍କୁ ଆଜି ଆପଣଙ୍କର ସମସ୍ତ Eloquent ଲିସେନର୍ସ ବାହାର କରିବାକୁ ପଡିବ ନାହିଁ। ଟ୍ରାଞ୍ଜିସନ୍ ଧୀରେ ଧୀରେ ହୋଇପାରେ। ଆପଣଙ୍କର ଆକ୍ସନ୍ କ୍ଲାସରୁ ଡୋମେନ୍ ଇଭେଣ୍ଟସ୍ ଏମିଟ୍ କରିବା ଆରମ୍ଭ କରନ୍ତୁ। ସମୟ ସହିତ, ଲିସେନର୍ସକୁ ସ୍ଥାନାନ୍ତର କରନ୍ତୁ। Eloquent ଲିସେନର୍ସକୁ ବଦଳାଇବା ସହିତ ସେଗୁଡିକୁ ଡିଲିଟ୍ କରନ୍ତୁ।

ନିଷ୍କର୍ଷ

ଫ୍ରେମୱାର୍କ ଇଭେଣ୍ଟ ହୁକ୍ସ ସୁବିଧାଜନକ, କିନ୍ତୁ ସେଗୁଡ଼ିକ ଏକ ସର୍ଟକଟ୍ ଅଟେ ଯାହା ଆପଣଙ୍କ କୋଡ୍ ବଢିବା ସହିତ ସ୍ପଷ୍ଟତା ଏବଂ ରକ୍ଷଣାବେକ୍ଷଣ କ୍ଷମତାର ମୂଲ୍ୟ ଦେଇଥାଏ। ଡୋମେନ୍ ଇଭେଣ୍ଟସ୍ ପାଇଁ ପ୍ରାରମ୍ଭରେ ଟିକିଏ ଅଧିକ ଚିନ୍ତା କରିବା ଆବଶ୍ୟକ ହୁଏ, କିନ୍ତୁ ସେଗୁଡ଼ିକ ସ୍କେଲ୍ କରେ। କ'ଣ ଘଟୁଛି ଏବଂ କାହିଁକି ଘଟୁଛି ସେ ବିଷୟରେ ସେଗୁଡ଼ିକ ସ୍ପଷ୍ଟ ଅଟେ। ସେଗୁଡ଼ିକ ଆପଣଙ୍କର ବିଜନେସ୍ ଲଜିକ୍ କୁ ଆପଣଙ୍କ ଫ୍ରେମୱାର୍କରୁ ଡିକପଲ୍ କରେ। ଯେତେବେଳେ ଏକ ବଗ୍ ଦେଖାଦିଏ, ଆପଣ ଜାଣନ୍ତି ସଠିକ୍ ଭାବରେ କେଉଁଠାରେ ଦେଖିବାକୁ ହେବ।

ଗୁଣ

• ଇଭେଣ୍ଟସ୍ ପ୍ରକୃତ ବିଜନେସ୍ ଆକ୍ସନ୍ କୁ ପ୍ରତିନିଧିତ୍ୱ କରେ, ଡାଟାବେସ୍ ଅପରେସନ୍ କୁ ନୁହେଁ
• କେଉଁ ଆକ୍ସନ୍ ପାଇଁ କେଉଁ ସାଇଡ୍ ଇଫେକ୍ଟସ୍ ଟ୍ରିଗର୍ ହୁଏ ତାହା ବୁଝିବା ସହଜ
• ଲିସେନର୍ସ ମଧ୍ୟରେ କୌଣସି ଲୁକ୍କାୟିତ ନିର୍ଭରଶୀଳତା ନାହିଁ
• ଫ୍ରେମୱାର୍କ-ଅଜ୍ଞେୟ—ଆପଣଙ୍କର ବିଜନେସ୍ ଲଜିକ୍ ଲାରାଭେଲ୍ ସହିତ ବନ୍ଧା ନାହିଁ
• ଫ୍ରେମୱାର୍କ ସେଟଅପ୍ ବିନା ସ୍ୱତନ୍ତ୍ର ଭାବରେ ଟେଷ୍ଟ୍ କରାଯାଇପାରିବ
• ଲିସେନର୍ସ କୁ ଇଚ୍ଛାକୃତ ଭାବରେ କ୍ରମାନ୍ୱୟ ଏବଂ ସମନ୍ୱିତ କରାଯାଇପାରିବ

ଦୋଷ

• ଫ୍ରେମୱାର୍କ ଲିସେନର୍ସ ତୁଳନାରେ ଅଧିକ ବଏଲରପ୍ଲେଟ୍ ଆବଶ୍ୟକ କରେ
• ଇଭେଣ୍ଟଗୁଡ଼ିକୁ ମାନୁଆଲୀ ଏମିଟ୍ କରିବାକୁ ପଡିବ; ଆପେ ଆପେ ହେବ ନାହିଁ
• ଡେଭଲପମେଣ୍ଟ ସମୟରେ ଅଧିକ ମାନସିକ ଚାପ
• ଶୃଙ୍ଖଳା ଆବଶ୍ୟକ କରେ—ଏକ ଇଭେଣ୍ଟ ଏମିଟ୍ କରିବାକୁ ଭୁଲିଯିବା ସହଜ ଅଟେ
• ଯଦି ଇଭେଣ୍ଟସ୍ ଲଗ୍ କରାଯାଇନଥାଏ ତେବେ ଡିବଗିଂ ଟିକିଏ କଷ୍ଟକର

ସତର୍କତା

ଏହି ଆର୍ଟିକିଲରେ ଥିବା ଉଦାହରଣ କୋଡ୍ ଏବଂ ପ୍ୟାଟର୍ଣ୍ଣ ନାମଗୁଡ଼ିକ ହେଉଛି ସାଧାରଣ ଉଦାହରଣ, ନିର୍ଦ୍ଦିଷ୍ଟ ପ୍ରଡକ୍ସନ୍ କୋଡ୍ ନୁହେଁ। ପ୍ରଡକ୍ସନରେ ଡିପ୍ଲୟ କରିବା ପୂର୍ବରୁ ଆପଣଙ୍କର ଇଭେଣ୍ଟ ଫ୍ଲୋକୁ ଭଲଭାବେ ଟେଷ୍ଟ କରନ୍ତୁ। ନିଜ ବିପଦରେ ଆଗକୁ ବଢନ୍ତୁ। ଯଦି ଆପଣ ବର୍ତ୍ତମାନ Eloquent ଇଭେଣ୍ଟସ୍ ବ୍ୟବହାର କରୁଛନ୍ତି, ଡୋମେନ୍ ଇଭେଣ୍ଟସକୁ ମାଇଗ୍ରେଟ୍ କରିବା ହେଉଛି ଏକ ରିଫାକ୍ଟରିଂ କାମ ଯାହା ଆପଣଙ୍କର ସାଇଡ୍ ଇଫେକ୍ଟସ୍ ପାଇଁ ଭଲ ଟେଷ୍ଟ୍ କଭରେଜ୍ ସହିତ ଯତ୍ନର ସହ କରାଯିବା ଉଚିତ୍।

ସାଧାରଣତଃ ପଚରାଯାଉଥିବା ପ୍ରଶ୍ନ (FAQ)

• ଯଦି ମୋର ଏକାଧିକ ଡୋମେନ୍ ଅଛି ଯାହାକୁ ଏକା ଆକ୍ସନ୍ ଉପରେ ପ୍ରତିକ୍ରିୟା କରିବାକୁ ପଡିବ ତେବେ କ'ଣ ହେବ?
• ଲିସେନର୍ସ ମଧ୍ୟରେ ଇଭେଣ୍ଟ ଅର୍ଡରିଂ ଏବଂ ନିର୍ଭରଶୀଳତାକୁ ମୁଁ କିପରି ହ୍ୟାଣ୍ଡେଲ କରିବି?
• କ'ଣ ମୁଁ ଇଲୋକ୍ୱେଣ୍ଟ ସହିତ ଡୋମେନ୍ ଇଭେଣ୍ଟସ୍ ବ୍ୟବହାର କରିପାରିବି, ନା ମୋତେ ଏକ ଭିନ୍ନ ORM ଦରକାର?
• ଯଦି ଏକ ଇଭେଣ୍ଟ ଲିସେନର୍ ବିଫଳ ହୁଏ ତେବେ କ'ଣ ହେବ—ସମ୍ପୂର୍ଣ୍ଣ ଟ୍ରାଞ୍ଜାକ୍ସନ୍ ରୋଲବ୍ୟାକ୍ ହେବ କି?
• ଡୋମେନ୍ ଇଭେଣ୍ଟ ଲିସେନର୍ସ କୁ ମୁଁ କିପରି ପୃଥକ୍ ଭାବରେ ଟେଷ୍ଟ୍ କରିବି?
• ଡାଟାବେସରେ ସେଭ୍ କରିବା ପୂର୍ବରୁ କିମ୍ବା ପରେ ମୁଁ ଡୋମେନ୍ ଇଭେଣ୍ଟସ୍ ଏମିଟ୍ କରିବା ଉଚିତ୍ କି?
• ଏକ ଡୋମେନ୍ ଇଭେଣ୍ଟ ଏବଂ ୱେବହୁକ୍ ମଧ୍ୟରେ ପାର୍ଥକ୍ୟ କ'ଣ?
• ଡୋମେନ୍ ଇଭେଣ୍ଟସ୍ ବ୍ୟବହାର କରିବା ସମୟରେ ମୁଁ ଇଭେଣ୍ଟୁଆଲ୍ କନସିଷ୍ଟେନ୍ସି କିପରି ହ୍ୟାଣ୍ଡେଲ କରିବି?

ଟ୍ୟାଗ୍ ଗୁଡ଼ିକ

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