2010-05-25 4 views
5

मैं आवेदन/डोमेन परत में डीडीडी का उपयोग कर event-sourced सीक्यूआरएस कार्यान्वयन पर काम कर रहा हूं।क्या किसी ईवेंट-सोर्स किए गए कुल रूट को सोर्सिंग रिपोजिटरी की सुविधा होनी चाहिए?

public class Person : AggregateRootBase 
{ 
    private Guid? _bookingId; 

    public Person(Identification identification) 
    { 
     Apply(new PersonCreatedEvent(identification)); 
    } 

    public Booking CreateBooking() { 
     // Enforce Person invariants 
     var booking = new Booking(); 
     Apply(new PersonBookedEvent(booking.Id)); 
     return booking; 
    } 

    public void Release() { 
     // Enforce Person invariants 
     // Should we load the booking here from the aggregate repository? 
     // We need to ensure that booking is released as well. 
     var booking = BookingRepository.Load(_bookingId); 
     booking.Release(); 
     Apply(new PersonReleasedEvent(_bookingId)); 
    } 

    [EventHandler] 
    public void Handle(PersonBookedEvent @event) { _bookingId = @event.BookingId; } 

    [EventHandler] 
    public void Handle(PersonReleasedEvent @event) { _bookingId = null; } 
} 

public class Booking : AggregateRootBase 
{ 
    private DateTime _bookingDate; 
    private DateTime? _releaseDate; 

    public Booking() 
    { 
     //Enforce invariants 
     Apply(new BookingCreatedEvent()); 
    } 

    public void Release() 
    { 
     //Enforce invariants 
     Apply(new BookingReleasedEvent()); 
    } 

    [EventHandler] 
    public void Handle(BookingCreatedEvent @event) { _bookingDate = SystemTime.Now(); } 
    [EventHandler] 
    public void Handle(BookingReleasedEvent @event) { _releaseDate = SystemTime.Now(); } 
    // Some other business activities unrelated to a person 
} 
DDD की मेरी समझ के साथ

अब तक, दोनों व्यक्ति और बुकिंग दो कारणों के लिए अलग कुल जड़ें हैं: मैं एक ऑब्जेक्ट मॉडल है कि इस तरह दिखता है

  1. रहे हैं बार जब व्यापार घटकों होगा डेटाबेस से अलग से बुकिंग ऑब्जेक्ट खींचें। (यानी, जारी किए गए व्यक्ति को गलत जानकारी के कारण पिछली बुकिंग में संशोधन किया गया है)।
  2. जब भी बुकिंग को अद्यतन करने की आवश्यकता होती है तो व्यक्ति और बुकिंग के बीच विवाद को लॉक नहीं करना चाहिए।

एक अन्य व्यावसायिक आवश्यकता यह है कि एक समय में एक बार एक व्यक्ति के लिए बुकिंग कभी नहीं हो सकती है। इसके कारण, मैं पठन पक्ष पर क्वेरी डेटाबेस से पूछताछ करने के बारे में चिंतित हूं क्योंकि संभावित रूप से वहां कुछ असंगतता हो सकती है (सीक्यूआरएस का उपयोग करने और अंत में लगातार पढ़ने वाले डेटाबेस होने के कारण)।

क्या कुल जड़ों को ऑब्जेक्ट्स के लिए आईडी द्वारा ईवेंट-सोर्स किए गए बैकिंग स्टोर से पूछने की अनुमति दी जानी चाहिए (आलसी लोडिंग उन्हें आवश्यकतानुसार)? क्या कार्यान्वयन के कोई अन्य मार्ग हैं जो अधिक समझ में आएंगे?

+0

"सार्वजनिक व्यक्ति (पहचान पहचान) { लागू करें (नई PersonCreatedEvent (पहचान)); }" आप स्मृति से वस्तु का निर्माण कर रहे है, तो क्या होता है, आप एक नया व्यक्ति नहीं बना रहे हैं, लेकिन आप प्रकाशित कर रहे एक नया कार्यक्रम मैं इवेंट हैंडलर को परिभाषित करने के तरीके को पसंद करता हूं।इसलिए यह जानकर कि किसी ऑब्जेक्ट की स्थिति केवल एक रिपॉजिटरी को कमांड लागू करते समय बदल सकती है, हो सकता है कि आपको कमांड हैंडलर भी जोड़ना चाहिए, जब तक कि आप पूरी घटना के आधार पर नहीं जा रहे हैं, जो आईएमएचओ इतना समझ नहीं लेता है। – Marco

+0

मुझे क्या पता नहीं चल रहा है कि आप एक ऐसी घटना को संभालने क्यों कर रहे हैं जिस पर आपका खुद का भंडार प्रकाशित होना चाहिए? "BookingCreatedEvent" – Marco

उत्तर

10

सबसे पहले, क्या आपको वास्तव में वास्तव में आपके मामले में सोर्सिंग की आवश्यकता है? यह मेरे लिए बहुत आसान लग रहा है। इवेंट सोर्सिंग में फायदे और नुकसान दोनों हैं। हालांकि यह आपको एक मुफ्त लेखापरीक्षा का निशान देता है और आपके डोमेन मॉडल को अधिक अभिव्यक्त बनाता है, यह समाधान को जटिल बनाता है।

ठीक है, मुझे लगता है कि इस बिंदु पर आपने अपने निर्णय पर विचार किया था और आप घटना सोर्सिंग के साथ रहने के लिए दृढ़ हैं। मुझे लगता है कि आप मैसेजिंग की अवधारणा को समेकन के बीच संचार के साधन के रूप में याद कर रहे हैं। यह Pat Helland's paper (जो बीटीडब्ल्यू है, डीडीडी या इवेंट सोर्सिंग के बारे में नहीं, बल्कि स्केलेबिलिटी के बारे में) में सबसे अच्छा वर्णन किया गया है।

विचार यह है कि कुछ योग कुछ व्यवहार को मजबूर करने के लिए संदेश भेज सकते हैं। समेकन के बीच कोई सिंक्रोनस (ए.के.ए विधि कॉल) इंटरैक्शन नहीं हो सकता है क्योंकि यह स्थिरता समस्याओं का परिचय देगा।

आपके उदाहरण में, एक व्यक्ति एआर एक बुकिंग एआर को एक रिजर्व संदेश भेज देगा। यह संदेश कुछ असीमित और भरोसेमंद तरीके से पहुंचाया जाएगा। बुकिंग एआर इस संदेश को संभालेगा और यदि यह पहले से किसी अन्य व्यक्ति द्वारा बुक किया गया है, तो यह आरक्षण रिजेक्शन संदेश के साथ जवाब देगा। अन्यथा, यह आरक्षण पुष्टि की जाएगी। इन संदेशों को व्यक्ति एआर द्वारा संभाला जाना होगा। शायद, वे एक और घटना उत्पन्न करेंगे जो ग्राहक को भेजे गए ई-मेल में परिवर्तित हो जाएगा या ऐसा कुछ।

मॉडल में क्वेरी डेटा लाने की कोई आवश्यकता नहीं है। बस संदेश। यदि आप एक उदाहरण चाहते हैं, तो आप Ncqrs प्रोजेक्ट की "संदेश" शाखा के स्रोत डाउनलोड कर सकते हैं और परिदृश्य टेस्ट क्लास पर एक नज़र डालें। यह ब्लू बुक से कार्गो और हैंडलिंग इवेंट नमूना का उपयोग कर एआरएस के बीच मैसेजिंग प्रदर्शित करता है।

क्या यह आपके प्रश्न का उत्तर देता है?

+1

यदि आप सिंक्रोनस हैंडलिंग को मजबूर करते हैं तो आप किस प्रकार की स्थिरता समस्याओं को चलाएंगे? ऐसा लगता है कि यह मेरे लिए स्केलेबिलिटी का मुद्दा होगा, लेकिन मुझे कुछ याद आ रहा है। –

+0

मुझे लगता है कि स्टोरेज मॉडल पार-कुल लेनदेन को संग्रहित करने का समर्थन नहीं करता है। यदि यह समर्थन करता है, तो आप सही हैं कि सामान्य विधि कॉल ठीक रहेगी (कम से कम जहां तक ​​स्थिरता का संबंध है)। –

+0

पैट हेलैंड के पेपर के माध्यम से देखने के बाद, मैं देखता हूं कि आप कहां से आ रहे हैं। इस विशेष प्रणाली में, मैं निकट-अनंत स्केलेबिलिटी से चिंतित नहीं हूं (हालांकि, यह एक अच्छी समस्या होगी)। एक कार्यान्वयन विस्तार के रूप में, हम एमएसएमक्यू का उपयोग कर रहे हैं। मेरा मानना ​​है कि एमएसएमक्यू का उपयोग कर 2 पीसी हमारे परिदृश्य में स्वीकार्य है। मुझे विचार पसंद है, हालांकि, और मुझे विचार के लिए भोजन दिया है। –

संबंधित मुद्दे