मुझे लगता है कि यदि आप मेटा डेटा के बजाय इवेंट पेलोड के हिस्से के रूप में प्रमोटर को स्टोर करते हैं तो यह अधिक फ्लेक्स होता है। सुरक्षा चिंताओं को डोमेन के बाहर संभाला जाना चाहिए। प्रत्येक ईवेंट उपयोगकर्ता द्वारा नहीं उठाया जाता है, हालांकि आप उनके लिए एक नकली बना सकते हैं (CronJob के लिए एक SysAdmin)।
उदाहरण के लिए:
ManualPaymentMadeEvent { //store this object as details in your schema
amount,
by_user//In this case, developers can determine whether store the promoter case by case
}
मुझे लगता है कि कक्षा के नाम पर्याप्त हैं। एक और तालिका जोड़ना जटिल घटना को पढ़ता है (तालिकाओं में शामिल होकर), और मुझे लगता है कि यह केवल तभी मूल्य जोड़ता है जब कक्षा के नाम का नाम बदल दिया जाता है (ईवेंट प्रकार तालिका में एक पंक्ति अपडेट करें)। लेकिन मुझे लगता है कि यह
. का उपयोग करने से ज्यादा परेशानी नहीं जोड़ता हैupdate domain_events set
aggregate_type = 'new class name'
where aggregate_type = 'origin class name'
मुझे यकीन नहीं है कि मैं इवेंट समूहों को समझता हूं, क्या आप और स्पष्टीकरण जोड़ सकते हैं?
कभी-कभी घटनाओं का उपयोग कई संदर्भों को एकीकृत करने के लिए किया जाता है। लेकिन प्रत्येक घटना को केवल एक संदर्भ में उठाया जाता है। उदाहरण के लिए, एक मैनुअलपेमेंटमेडइवेंट को ऑर्डरिंग संदर्भ में उठाया जाता है, और शिपिंग संदर्भ में एक ईवेंट लिस्टर भी इसका उपभोग करता है, इसे स्टार्ट शिपिंग के ट्रिगर के रूप में मानता है।
मैं प्रति संदर्भ प्रति डेटाबेस उपयोगकर्ता (ओरेकल टर्म) का उपयोग करना पसंद करता हूं। शिपिंग संदर्भ के लिए Shipping.domain_events और ऑर्डरिंग प्रसंग के लिए ordering.domain_events.
यह axon-framework में स्कीमा है जो मदद कर सकता है
create table DomainEventEntry (
aggregateIdentifier varchar2(255) not null,
sequenceNumber number(19,0) not null,
type varchar2(255) not null, --aggregate class name
eventIdentifier varchar2(255) not null,
metaData blob,
payload blob not null, -- details
payloadRevision varchar2(255),
payloadType varchar2(255) not null, --event class name
timeStamp varchar2(255) not null
);
alter table DomainEventEntry
add constraint PK_DomainEventEntry primary key (aggregateIdentifier, sequenceNumber, type);