ইভেন্ট সোর্সিংয়ে আমি কীভাবে পার্শ্ব প্রতিক্রিয়াগুলি মোকাবিলা করব?

Question

আসুন ধরে নেওয়া যাক আমরা একটি আর্থিক অ্যাপ্লিকেশনটির জন্য একটি ছোট সুরক্ষা সাবসিস্টেমটি প্রয়োগ করতে চাই যা কোনও অদ্ভুত প্যাটার্ন সনাক্ত হলে ইমেলের মাধ্যমে ব্যবহারকারীদের সাবধান করে দেয়। এই উদাহরণস্বরূপ, প্যাটার্নটি তিনটি লেনদেনের সাথে চিত্রিত হিসাবে থাকবে। সুরক্ষা সাবসিস্টেমটি একটি সারি থেকে মূল সিস্টেমের ইভেন্টগুলি পড়তে পারে।

আমি যা পেতে চাই তা হ'ল একটি সতর্কতা যা সিস্টেমে ঘটে যাওয়া ইভেন্টগুলির প্রত্যক্ষ পরিণতি, মধ্যবর্তী প্রতিনিধিত্ব ছাড়াই যা প্যাটার্নের বর্তমান অবস্থার মডেল করে।

1. পর্যবেক্ষণ সক্রিয় করা হয়েছে
2. লেনদেন প্রক্রিয়াজাত
3. লেনদেন প্রক্রিয়াজাত
4. লেনদেন প্রক্রিয়াজাত
5. সতর্কতা ট্রিগার করা হয়েছে (আইডি: 123)
6. সতর্কতার জন্য ইমেল প্রেরণ করা হয়েছে (আইডি: 123)
7. লেনদেন প্রক্রিয়াজাত

এটি মনে রেখে, আমি ভেবেছিলাম ইভেন্ট সোর্সিং এখানে খুব ভাল প্রয়োগ হতে পারে, যদিও আমার একটি পরিষ্কার উত্তর ছাড়াই একটি প্রশ্ন রয়েছে। উদাহরণে ট্রিগার হওয়া সতর্কতার একটি স্পষ্ট পার্শ্ব প্রতিক্রিয়া রয়েছে, একটি ইমেল প্রেরণ করা দরকার, এমন পরিস্থিতি যা কেবল একবার ঘটতে পারে। সুতরাং, সামগ্রিক সমস্ত ইভেন্টের পুনরায় খেলতে গিয়ে এটি হওয়া উচিত নয়।

কিছুটা হলেও, আমি ইমেলটি দেখতে পাচ্ছি যে সিকিউরিআরএস / ইভেন্ট স্যোসরিং সাহিত্যে আমি এতবার দেখলাম না যে কোয়েরি সাইড দ্বারা উত্পন্ন বস্তুগতকরণের অনুরূপ প্রেরণ করা দরকার, যদিও এর মধ্যে খুব সূক্ষ্ম পার্থক্য নেই।

এই সাহিত্যে, ক্যোয়ারী সাইডটি ইভেন্ট হ্যান্ডলারের কাছ থেকে তৈরি করা হয়েছে যা কোনও নির্দিষ্ট সময়ে রাষ্ট্রের একটি বস্তুগতকরণ তৈরি করতে পারে আবার সমস্ত ইভেন্ট পড়ে। যদিও এক্ষেত্রে আগে বর্ণিত কারণের কারণে ঠিক এমনটি করা সম্ভব নয়। প্রতিটি রাজ্য ক্ষণস্থায়ী এই ধারণাটি এখানে এত ভাল প্রয়োগ হয় না । আমাদের কোথাও একটি সতর্কতা প্রেরণ করা হয়েছিল তা রেকর্ড করতে হবে।

আমার জন্য একটি সহজ সমাধান হতে পারে একটি আলাদা টেবিল বা কাঠামো যেখানে আপনি আগে সঞ্চিত সতর্কতাগুলির রেকর্ড রাখেন। আমাদের একটি আইডি আছে তাই আমরা আগে একই আইডি সহ একটি সতর্কতা জারি করা হয়েছে কিনা তা খতিয়ে দেখতে সক্ষম হব। এই তথ্যটি রাখলে সেন্ডআলার্টকম্যান্ডকে আদর্শবান করে তুলবে। বেশ কয়েকটি কমান্ড জারি করা যেতে পারে তবে পার্শ্ব প্রতিক্রিয়াটি কেবল একবার ঘটবে।

এমনকি সেই সমাধানটি মাথায় রেখেও আমি জানি না যে এটি কোনও ইঙ্গিত কিনা এই সমস্যার জন্য এই আর্কিটেকচারে কিছু ভুল আছে কিনা।

• আমার পদ্ধতির সঠিক?
• এমন কোনও জায়গা আছে যেখানে আমি এই সম্পর্কে আরও তথ্য জানতে পারি?

এটি আশ্চর্যজনক যে আমি এই সম্পর্কে আরও তথ্য সন্ধান করতে সক্ষম হইনি। আমি ভুল শব্দ ব্যবহার করা হয়েছে।

তোমাকে অনেক ধন্যবাদ!

Answer 1

ইভেন্ট সোর্সিংয়ে আমি কীভাবে পার্শ্ব প্রতিক্রিয়াগুলি মোকাবিলা করব?

সংক্ষিপ্ত সংস্করণ: ডোমেন মডেল পার্শ্ব প্রতিক্রিয়া সম্পাদন করে না। এটি তাদের ট্র্যাক করে। পার্শ্ব প্রতিক্রিয়া সীমানার সাথে সংযোগকারী একটি বন্দর ব্যবহার করে সঞ্চালিত হয়; ইমেল প্রেরিত হলে, আপনি স্বীকৃতিটি ডোমেন মডেলটিতে ফেরত পাঠান।

এর অর্থ হ'ল ইমেলটি লেনদেনের বাইরে প্রেরণ করা হয়েছে যা ইভেন্টের স্ট্রিম আপডেট করে।

ঠিক যেখানে, বাইরে, স্বাদের বিষয়।

সুতরাং ধারণাগতভাবে, আপনার মতো ইভেন্টগুলির একটি স্ট্রিম রয়েছে

EmailPrepared(id:123)
EmailPrepared(id:456)
EmailPrepared(id:789)
EmailDelivered(id:456)
EmailDelivered(id:789)

এবং এই স্ট্রিম থেকে আপনি একটি ভাঁজ তৈরি করতে পারেন

{
    deliveredMail : [ 456, 789 ],
    undeliveredMail : [123]
}

ভাঁজ আপনাকে জানায় কোন ইমেলগুলি স্বীকৃত হয়নি, তাই আপনি সেগুলি আবার প্রেরণ করুন:

undeliveredMail.each ( mail -> {
    send(mail);
    dispatch( new EmailDelivered.from(mail) );
}     

কার্যকরভাবে, এটি একটি দুটি পর্যায়ের অঙ্গীকার: আপনি আসল বিশ্বে এসএমটিপি পরিবর্তন করছেন এবং তারপরে আপনি মডেলটি আপডেট করছেন।

উপরের প্যাটার্নটি আপনাকে কমপক্ষে একবারে বিতরণ মডেল দেয়। আপনি যদি একবারেও চান তবে আপনি এটি ঘুরিয়ে দিতে পারেন

undeliveredMail.each ( mail -> {
    commit( new EmailDelivered.from(mail) );
    send(mail);
}     

ইমেলপ্রেপডকে টেকসই করা এবং আসলে ইমেল প্রেরণের মধ্যে একটি লেনদেনের বাধা রয়েছে। ইমেল প্রেরণ এবং ইমেলডেলিভার্ডকে টেকসই করার মধ্যে একটি লেনদেনের বাধাও রয়েছে।

বিতরণ লেনদেনের সাথে উদীয় দাহানের নির্ভরযোগ্য বার্তা পাঠানো একটি ভাল সূচনা পয়েন্ট হতে পারে।

Answer 2

আপনার 'রাষ্ট্রীয় পরিবর্তন ইভেন্টগুলি' কে 'ক্রিয়া' থেকে আলাদা করতে হবে

একটি অবস্থা পরিবর্তন ইভেন্ট একটি ইভেন্ট যে বস্তুর অবস্থা পরিবর্তন হলে হয়। এগুলি আপনি সংরক্ষণ এবং পুনরায় খেলুন।

একটি ক্রিয়া হ'ল জিনিসটি অন্য জিনিসগুলির সাথে করে। এগুলি ইভেন্ট সোর্সিংয়ের অংশ হিসাবে সংরক্ষণ করা হয় না।

এটি করার একটি উপায় হ'ল ইভেন্ট হ্যান্ডারগুলির সাথে, যা আপনি তারের ওয়্যার আপ করেন বা আপনি অ্যাকশনগুলি চালাতে চান কিনা তার উপর নির্ভর করে।

public class Monitor
{
    public EventHander SoundAlarm;
    public void MonitorEvent(Event e)
    {
        this.eventcount ++;
        if(this.eventcount > 10)
        {
             this.state = "ALARM!";
             if(SoundAlarm != null) { SoundAlarm();}
        }
    }
}

এখন আমার নিরীক্ষণ পরিষেবাতে আমি থাকতে পারি

public void MonitorServer()
{
    var m = new Monitor(events); //11 events
    //alarm has not been sounded because the event handler wasn't wired up
    //but the internal state is correctly set to "ALARM!"
    m.SoundAlarm += this.SendAlarmEmail;
    m.MonitorEvent(e); //email is sent
}

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