DDD इकाई राज्य संक्रमण

Question

निम्नलिखित सरल उदाहरण पर विचार करें। बाद में टिकट के जीवन चक्र में अन्य राज्यों को स्थापित किया जा सकता है।

टिकट टिकट तालिका के साथ-साथ टिकटस्टेट में भी जारी है। तो डीबी के भीतर टिकट टिकट राज्य तालिका के लिए एक विदेशी कुंजी होगी।

जब मेरी यूनिट के भीतर उपयुक्त राज्य की स्थापना, मैं कैसे डीबी से राज्य उदाहरण लोड करूं? क्या मुझे इकाई में एक भंडार इंजेक्ट करना है? क्या मुझे ऐसे मामले के लिए महल जैसे ढांचे का उपयोग करने की ज़रूरत है? या क्या बेहतर समाधान हैं, शायद बाहर से राज्य को पारित कर रहे हैं?

public class Ticket 
{ 
    //... 
    public ITicketStateRepository stateRep; //<-- inject 

    public Ticket() 
    { 
     State = stateRep.GetById(NEW_STATE_ID); 
    } 
    //... 
} 

क्या कोई सर्वोत्तम अभ्यास है? अब तक मैं किसी भी निर्भरता इंजेक्शन ढांचे या कुछ भी उपयोग नहीं किया है और मैं डोमेन से बाहर एक और approch किसी भी हठ बातें रखा ..

:

public class Ticket 
{ 
    //... 

    public Ticket(NewTicketState newTicketState) 
    { 
     State = newTicketState; 
    } 
    public void Finished(FinishedTicketState finishedTicketState) 
    { 
     State = finishedTicketState; 
    } 
    //... 
} 

Answer 1

टिकट भंडार के लिए एक संदर्भ नहीं होगा। यह टिकटस्टेट के साथ एक-से-एक संबंध होगा, और टिकट रिपोजिटरी बस जॉइन करेगी और टिकटों को टिकट में मैप करेगी।

जब मैं मॉडल वस्तुओं मैं आम तौर पर उन्हें या नहीं, वे लगातार कर रहे हैं के बारे में पता नहीं बनाते हैं बनाने के लिए, ताकि वे एक भंडार का इंजेक्शन नहीं कर रहे हैं। भंडार सभी सीआरयूडी संचालन को संभालता है।

कुछ लोग इस पर आपत्ति करते हुए कहा कि यह एक anemic domain model की ओर जाता है; शायद आप उनमें से एक हैं। यदि ऐसा है, तो अपने टिकट ऑब्जेक्ट में रिपोजिटरी इंजेक्ट करें, लेकिन सरल इसे जॉइन करने के लिए कहें और अपने राज्य के साथ एक टिकट वापस कर दें। जब आप सम्मिलित करते हैं या अपडेट करते हैं तो आपको दो टेबल को काम की एक इकाई के रूप में संशोधित करना होता है, इसलिए सुनिश्चित करें कि लेनदेन चालू हो।

कारण मैं डोमेन मॉडल वस्तु बाहर CRUD ऑप्स लेना पसंद है कि यह आमतौर पर केवल डोमेन वस्तु एक उपयोग के मामले या लेन-देन में भाग लेने वाले नहीं है। उदाहरण के लिए, हो सकता है कि आपका सरल "खरीद टिकट" उपयोग केस में टिकट ऑब्जेक्ट होगा, लेकिन कुछ अन्य ऑब्जेक्ट्स भी हो सकती हैं जो आरक्षण और बैठने और सामान्य खाताधारक और सामान की सूची और अन्य सभी प्रकार की चीजों से निपटती हैं। आप वास्तव में काम की एक इकाई के रूप में कई मॉडल वस्तुओं को जारी रखना चाहते हैं। केवल सेवा स्तर ही जान सकता है कि जब मॉडल ऑब्जेक्ट अपने आप पर कार्य कर रहा है और जब यह एक बड़ी, ग्रैंडर प्लान का हिस्सा है।

अद्यतन:

एक और कारण है कि मैं एक डीएओ के साथ एक मॉडल वस्तु इंजेक्शन तो यह हठ कर्तव्यों संभाल कर सकते हैं के विचार पसंद नहीं है परतों के trashing और चक्रीय निर्भरता यह परिचय है। यदि आप दृढ़ता कक्षाओं के किसी भी संदर्भ से मॉडल को साफ रखते हैं तो आप उन्हें अन्य परत का आह्वान किए बिना उपयोग कर सकते हैं। यह एक तरफा निर्भरता है; दृढ़ता मॉडल के बारे में जानता है, लेकिन मॉडल दृढ़ता के बारे में नहीं जानता है।

मॉडल में दृढ़ता सम्मिलित करें और वे cyclicly एक दूसरे पर निर्भर कर रहे हैं। आप बिना किसी के किसी एक का उपयोग या परीक्षण कर सकते हैं। कोई लेयरिंग नहीं, चिंताओं का कोई अलगाव नहीं।

Answer 2

यह उत्तर उम्मीद है कि डफिमो से है।

दुनिया के एक DDD ध्यान में रखते हुए अपने TicketState एक इकाई है कि टिकट कुल (जहां एक टिकट कुल जड़ है) का हिस्सा है।

इसके बाद, आपकी टिकट रिपोजिटरी टिकट, और टिकटस्टेट दोनों के साथ सौदा करती है।

जब आप दृढ़ता परत से टिकट प्राप्त करते हैं तो आप अपने टिकट रिपोजिटरी को राज्य को डीबी से पुनर्प्राप्त करने और उसे सही ढंग से टिकट पर सेट करने की अनुमति देते हैं।

यदि आप टिकट खरीद रहे हैं तो (मुझे लगता है) आपको अभी तक डेटाबेस को स्पर्श करने की आवश्यकता नहीं है। जब टिकट अंततः जारी रहता है, तो आप टिकट की नई स्थिति लेने और इसे सही तरीके से जारी रखने के बजाय।

आपके डोमेन कक्षाओं को राज्य की देखभाल करने वाले डेटाबेस मॉडल के बारे में कुछ भी जानने की आवश्यकता नहीं है, उन्हें केवल राज्य के डोमेन मॉडल दृश्य के बारे में जानना चाहिए। तब आपकी रिपोजिटरी इस मैपिंग के लिए ज़िम्मेदार है।

Answer 3

मेरे लिए, डेटाबेस में राज्य का प्रतिनिधित्व करने वाली एक साधारण कुंजी-मूल्य जोड़ी (या जो भी दृढ़ता माध्यम) को डोमेन में इस तरह मॉडल करने की आवश्यकता नहीं है। डोमेन में, मैं टिकटस्टेट को एक enum बना दूंगा, और यह डेटाबेस स्कीमा की आवश्यकताओं को मैप करने के तरीके के बारे में जानने के लिए ITicketRepository की ज़िम्मेदारी बनाउंगा।

टिकट भंडार के भीतर, आप टिकटस्टेट पर कुंजी टिकट आईडी आईडी का कैश कर सकते हैं, जो डाटाबेस से एक स्थैतिक चर (केवल एक दृष्टिकोण) में आलसी भरा हुआ है। टिकट भंडार टिकट को मानचित्रित करेगा। उस कैश से आईडी को आवेषण/अपडेट के लिए आईडी मान करें।

namespace Domain { 
    public class Ticket { 
    public Ticket() { State = TicketStates.New; } 
    public void Finish() { State = TicketStates.Finished; } 
    public TicketStates State {get;set;} 
    } 

    public enum TicketState { New, Finished } 
} 

namespace Repositories { 
    public class SqlTicketRepository : ITicketRepository { 
    public void Save(Ticket ticket) { 
     using (var tx = new TransactionScope()) { // or whatever unit of work mechanism 
     int newStateId = TicketStateIds[ticket.State]; 
     // update Ticket table with newStateId 
     } 
    } 
    } 

    private Dictionary<TicketState, int> _ticketStateIds; 
    protected Dictionary<TicketState, int> TicketStateIds{ 
    get { 
     if (_ticketStateIds== null) 
     InitializeTicketStateIds(); 
     return _ticketStateIds; 
    } 
    } 

    private void InitializeTicketStateIds() { 
    // execute SQL to get all key-values pairs from TicketStateValues table 
    // use hard-coded mapping from strings to enum to populate _ticketStateIds; 
    } 
}