🥔 ◀️ 👳 डोमेन ड्रिवेन डिज़ाइन: प्रैक्टिस में वैल्यू ऑब्जेक्ट्स और एंटिटी फ्रेमवर्क कोर ⛔️ 👲🏻 🤦🏿

Habré पर और न केवल लेखों का एक सभ्य राशि डोमेन ड्रिवेन डिज़ाइन के बारे में लिखा गया है - सामान्य रूप से वास्तुकला के बारे में, और उदाहरण के लिए .Net के साथ। लेकिन साथ ही, इस वास्तुकला का एक महत्वपूर्ण हिस्सा मूल्य वस्तुओं के रूप में अक्सर खराब उल्लेख किया जाता है।

इस लेख में, मैं एंटिटी फ्रेमवर्क कोर का उपयोग करके .Net कोर में मूल्य वस्तुओं को लागू करने की बारीकियों को उजागर करने का प्रयास करूंगा।

एक बिल्ली के नीचे बहुत सारे कोड होते हैं।

सिद्धांत की बिट

डोमेन ड्रिवेन डिज़ाइन की वास्तुकला का मूल डोमेन है - वह विषय क्षेत्र जिस पर विकसित किया जा रहा सॉफ़्टवेयर लागू किया जाता है। यहां एप्लिकेशन का संपूर्ण व्यावसायिक तर्क है, जो आमतौर पर विभिन्न डेटा के साथ बातचीत करता है। डेटा दो प्रकार के हो सकते हैं:

इकाई वस्तु
मान ऑब्जेक्ट (इसके बाद - VO)

एंटिटी ऑब्जेक्ट व्यावसायिक तर्क में एक इकाई को परिभाषित करता है और हमेशा एक पहचानकर्ता होता है जिसके द्वारा एंटिटी को दूसरे एंटिटी के साथ पाया या तुलना किया जा सकता है। यदि दो एंटिटी में एक समान पहचानकर्ता है, तो यह एक ही एंटिटी है। लगभग हमेशा बदलते रहते हैं।
वैल्यू ऑब्जेक्ट एक अपरिवर्तनीय प्रकार है, जिसका मूल्य निर्माण के दौरान निर्धारित होता है और ऑब्जेक्ट के पूरे जीवन में नहीं बदलता है। इसकी पहचान नहीं है। यदि दो VO संरचनात्मक रूप से समान हैं, तो वे समतुल्य हैं।

इकाई में अन्य इकाई और VO शामिल हो सकते हैं। वीओ में अन्य वीओ शामिल हो सकते हैं, लेकिन एंटिटी नहीं।

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

एक उदाहरण है। विभिन्न नियमावली में, सभी को बीमार करने वाले व्यक्ति वर्ग को अक्सर इस तरह दिखाया जाता है:

public class Person { public int Id { get; set; } public string Name { get; set; } public int Age { get; set; } }

सरल और स्पष्ट - पहचानकर्ता, नाम और उम्र, आप कहां गलती कर सकते हैं?

लेकिन यहां कई त्रुटियां हो सकती हैं - उदाहरण के लिए, व्यापारिक तर्क के दृष्टिकोण से, एक नाम अनिवार्य है, यह शून्य लंबाई या 100 से अधिक वर्ण नहीं हो सकता है और इसमें विशेष वर्ण, विराम चिह्न आदि नहीं होने चाहिए। और आयु 10 वर्ष से कम या 120 वर्ष से अधिक नहीं हो सकती है।

प्रोग्रामिंग भाषा के दृष्टिकोण से, 5 पूरी तरह से सामान्य पूर्णांक है, इसी तरह एक खाली स्ट्रिंग। लेकिन डोमेन पहले से ही गलत स्थिति में है।

अभ्यास के लिए आगे बढ़ते हैं

इस बिंदु पर, हम जानते हैं कि VO को अपरिवर्तनीय होना चाहिए और इसमें एक मान होना चाहिए जो व्यावसायिक तर्क के लिए मान्य है।

ऑब्जेक्ट बनाने के दौरान रीडऑनली प्रॉपर्टी को इनिशियलाइज़ करके इम्यूनिटी हासिल की जाती है।
मूल्य का सत्यापन कंस्ट्रक्टर (गार्ड क्लॉज) में होता है। सत्यापन को स्वयं सार्वजनिक रूप से उपलब्ध करना वांछनीय है - ताकि अन्य परतें क्लाइंट (उसी ब्राउज़र) से प्राप्त डेटा को मान्य कर सकें।

आइए नाम और आयु के लिए एक VO बनाएं। इसके अतिरिक्त, हम कार्य को थोड़ा जटिल करते हैं - FirstName और LastName के संयोजन में एक व्यक्तिगत नाम जोड़ें और इसे व्यक्ति पर लागू करें।

नाम

 public class Name { private static readonly Regex ValidationRegex = new Regex( @"^[\p{L}\p{M}\p{N}]{1,100}\z", RegexOptions.Singleline | RegexOptions.Compiled); public Name(String value) { if (!IsValid(value)) { throw new ArgumentException("Name is not valid"); } Value = value; } public String Value { get; } public static Boolean IsValid(String value) { return !String.IsNullOrWhiteSpace(value) && ValidationRegex.IsMatch(value); } public override Boolean Equals(Object obj) { return obj is Name other && StringComparer.Ordinal.Equals(Value, other.Value); } public override Int32 GetHashCode() { return StringComparer.Ordinal.GetHashCode(Value); } }

PersonalName

 public class PersonalName { protected PersonalName() { } public PersonalName(Name firstName, Name lastName) { if (firstName == null) { throw new ArgumentNullException(nameof(firstName)); } if (lastName == null) { throw new ArgumentNullException(nameof(lastName)); } FirstName = firstName; LastName = lastName; } public Name FirstName { get; } public Name LastName { get; } public String FullName => $"{FirstName} {LastName}"; public override Boolean Equals(Object obj) { return obj is PersonalName personalName && EqualityComparer<Name>.Default.Equals(FirstName, personalName.FirstName) && EqualityComparer<Name>.Default.Equals(LastName, personalName.LastName); } public override Int32 GetHashCode() { return HashCode.Combine(FirstName, LastName); } public override String ToString() { return FullName; } }

आयु

 public class Age { public Age(Int32 value) { if (!IsValid(value)) { throw new ArgumentException("Age is not valid"); } Value = value; } public Int32 Value { get; } public static Boolean IsValid(Int32 value) { return 10 <= value && value <= 120; } public override Boolean Equals(Object obj) { return obj is Age other && Value == other.Value; } public override Int32 GetHashCode() { return Value.GetHashCode(); } }

और अंत में व्यक्ति:

 public class Person { public Person(PersonalName personalName, Age age) { if (personalName == null) { throw new ArgumentNullException(nameof(personalName)); } if (age == null) { throw new ArgumentNullException(nameof(age)); } Id = Guid.NewGuid(); PersonalName= personalName; Age = age; } public Guid Id { get; private set; } public PersonalName PersonalName{ get; set; } public Age Age { get; set; } }

इसलिए, हम एक पूर्ण नाम या आयु के बिना व्यक्ति नहीं बना सकते। इसके अलावा, हम "गलत" नाम या "गलत" उम्र नहीं बना सकते। एक अच्छा प्रोग्रामर निश्चित रूप से Name.IsValid ("जॉन") और Age.IsValid (35) विधियों का उपयोग करके नियंत्रक में प्राप्त डेटा की जांच करेगा और गलत डेटा के मामले में ग्राहक को इस बारे में सूचित करेगा।

यदि हम केवल एंटिटी और VO का उपयोग करने के लिए मॉडल में हर जगह एक नियम बनाते हैं, तो हम बड़ी संख्या में त्रुटियों से खुद की रक्षा करेंगे - गलत डेटा बस मॉडल में नहीं मिलेगा।

हठ

अब हमें अपने डेटा को डेटा वेयरहाउस में सहेजने और अनुरोध पर प्राप्त करने की आवश्यकता है। हम ORM के रूप में एंटिटी फ्रेमवर्क कोर का उपयोग करेंगे, और डेटा वेयरहाउस MS SQL सर्वर है।

डीडीडी स्पष्ट रूप से परिभाषित करता है: दृढ़ता बुनियादी ढांचे की परत की एक उप-प्रजाति है क्योंकि यह डेटा पहुंच के एक विशिष्ट कार्यान्वयन को छुपाता है।

डोमेन को पर्सिस्टेंस के बारे में कुछ भी जानने की आवश्यकता नहीं है, यह केवल रिपॉजिटरी के इंटरफेस को निर्धारित करता है।

और दृढ़ता में विशिष्ट कार्यान्वयन शामिल हैं, कॉन्फ़िगरेशन को मैप करना, साथ ही एक UnitOfWork ऑब्जेक्ट।

इसमें दो राय है कि क्या यह रिपोजिटरी और यूनिट ऑफ वर्क बनाने के लायक है।

एक ओर - नहीं, यह आवश्यक नहीं है, क्योंकि एंटिटी फ्रेमवर्क कोर में यह सब पहले से ही लागू है। अगर हमारे पास DAL -> बिजनेस लॉजिक -> प्रेजेंटेशन का एक बहु-स्तरीय आर्किटेक्चर है, जो डेटा स्टोरेज पर आधारित है, तो सीधे EF Core की क्षमताओं का उपयोग क्यों न करें।

लेकिन DDD में डोमेन डेटा संग्रहण और उपयोग किए गए ORM पर निर्भर नहीं करता है - ये कार्यान्वयन की सभी सूक्ष्मताएं हैं जो दृढ़ता में संलग्न हैं और किसी और के लिए कोई रुचि नहीं हैं। यदि हम अन्य परतों को DbContext प्रदान करते हैं, तो हम तुरंत कार्यान्वयन विवरणों का खुलासा करते हैं, कसकर चयनित ORM से बांधते हैं और DAL प्राप्त करते हैं - सभी व्यावसायिक तर्क के आधार के रूप में, लेकिन यह नहीं होना चाहिए। मोटे तौर पर, डोमेन को ओआरएम में बदलाव और यहां तक कि एक परत के रूप में दृढ़ता के नुकसान को ध्यान नहीं देना चाहिए।

तो, डोमेन में व्यक्ति रिपॉजिटरी इंटरफ़ेस,

 public interface IPersons { Task Add(Person person); Task<IReadOnlyList<Person>> GetList(); }

और दृढ़ता में इसका कार्यान्वयन:

 public class EfPersons : IPersons { private readonly PersonsDemoContext _context; public EfPersons(UnitOfWork unitOfWork) { if (unitOfWork == null) { throw new ArgumentNullException(nameof(unitOfWork)); } _context = unitOfWork.Context; } public async Task Add(Person person) { if (person == null) { throw new ArgumentNullException(nameof(person)); } await _context.Persons.AddAsync(person); } public async Task<IReadOnlyList<Person>> GetList() { return await _context.Persons.ToListAsync(); } }

ऐसा लगता है कि कुछ भी जटिल नहीं है, लेकिन एक समस्या है। आउट ऑफ द बॉक्स एंटिटी फ्रेमवर्क कोर केवल बुनियादी प्रकार (स्ट्रिंग, इंट, डेटाइम, आदि) के साथ काम करता है और व्यक्तिगत नाम और आयु के बारे में कुछ भी नहीं जानता है। आइए हमारी मूल्य वस्तुओं को समझने के लिए ईएफ कोर सिखाएं।

विन्यास

धाराप्रवाह एपीआई डीडीडी में एंटिटी को कॉन्फ़िगर करने के लिए सबसे उपयुक्त है। विशेषताएँ उपयुक्त नहीं हैं, क्योंकि डोमेन को मानचित्रण की बारीकियों के बारे में कुछ भी जानने की आवश्यकता नहीं है।

मूल विन्यास के साथ दृढ़ता में एक वर्ग बनाएँ

 internal class PersonConfiguration : IEntityTypeConfiguration<Person> { public void Configure(EntityTypeBuilder<Person> builder) { builder.ToTable("Persons"); builder.HasKey(p => p.Id); builder.Property(p => p.Id).ValueGeneratedNever(); } }

और इसे DbContext में प्लग करें:

 protected override void OnModelCreating(ModelBuilder builder) { base.OnModelCreating(builder); builder.ApplyConfiguration(new PersonConfiguration()); }

मानचित्रण

वह अनुभाग जिसके लिए यह सामग्री लिखी गई थी।

फिलहाल, गैर-मानक कक्षाओं को आधार प्रकारों के लिए मैप करने के दो और कम सुविधाजनक तरीके हैं - मूल्य रूपांतरण और स्वामित्व प्रकार।

मूल्य रूपांतरण

यह सुविधा इकाई फ्रेमवर्क कोर 2.1 में दिखाई दी और आपको दो डेटा प्रकारों के बीच रूपांतरण निर्धारित करने की अनुमति देती है।

आइए आयु के लिए कनवर्टर लिखें (इस खंड में सभी कोड पर्सनऑफिग्रेशन में है):

 var ageConverter = new ValueConverter<Age, Int32>( v => v.Value, v => new Age(v)); builder .Property(p => p.Age) .HasConversion(ageConverter) .HasColumnName("Age") .HasColumnType("int") .IsRequired();

सरल और संक्षिप्त वाक्य रचना, लेकिन दोषों के बिना नहीं:

अशक्त कन्वर्ट करने में असमर्थ;
एक एकल संपत्ति को एक तालिका में कई स्तंभों में बदलना संभव नहीं है और इसके विपरीत;
EF Core इस प्रॉपर्टी के साथ LINQ एक्सप्रेशन को SQL क्वेरी में नहीं बदल सकता है।

मैं अधिक विस्तार से अंतिम बिंदु पर ध्यान केंद्रित करूंगा। दी गई उम्र में व्यक्ति की सूची देने वाले भंडार में एक विधि जोड़ें:

 public async Task<IReadOnlyList<Person>> GetOlderThan(Age age) { if (age == null) { throw new ArgumentNullException(nameof(age)); } return await _context.Persons .Where(p => p.Age.Value > age.Value) .ToListAsync(); }

आयु के लिए एक शर्त है, लेकिन EF Core इसे SQL क्वेरी में परिवर्तित करने में सक्षम नहीं होगा और, जहाँ तक पहुँचते हुए (), यह पूरी मेज को एप्लिकेशन मेमोरी में लोड कर देगा और उसके बाद ही, LINQ का उपयोग करते हुए, यह शर्त को पूरा करेगा। p.ge.Value> age.Value ।

सामान्य तौर पर, मूल्य रूपांतरण एक सरल और त्वरित मानचित्रण विकल्प है, लेकिन आपको ईएफ कोर की इस विशेषता के बारे में याद रखने की आवश्यकता है, अन्यथा, किसी बिंदु पर, बड़ी तालिकाओं को क्वेरी करते समय, स्मृति बाहर निकल सकती है।

स्वामित्व प्रकार

स्वामित्व वाले प्रकार एंटिटी फ्रेमवर्क कोर 2.0 में दिखाई दिए और नियमित एंटिटी फ्रेमवर्क से जटिल प्रकारों को प्रतिस्थापित किया।

आइए आयु को स्वामित्व प्रकार के रूप में बनाएं:

 builder.OwnsOne(p => p.Age, a => { a.Property(u => u.Value).HasColumnName("Age"); a.Property(u => u.Value).HasColumnType("int"); a.Property(u => u.Value).IsRequired(); });

बुरा नहीं है। और स्वामित्व प्रकारों के मूल्य रूपांतरणों के कुछ नुकसान नहीं हैं, अर्थात् अंक 2 और 3।

2. तालिका में एक संपत्ति को कई स्तंभों में बदलना संभव है और इसके विपरीत

आपको PersonalName के लिए क्या चाहिए, हालाँकि सिंटैक्स पहले से ही थोड़ा अधिक भरा हुआ है:

 builder.OwnsOne(b => b.PersonalName, pn => { pn.OwnsOne(p => p.FirstName, fn => { fn.Property(x => x.Value).HasColumnName("FirstName"); fn.Property(x => x.Value).HasColumnType("nvarchar(100)"); fn.Property(x => x.Value).IsRequired(); }); pn.OwnsOne(p => p.LastName, ln => { ln.Property(x => x.Value).HasColumnName("LastName"); ln.Property(x => x.Value).HasColumnType("nvarchar(100)"); ln.Property(x => x.Value).IsRequired(); }); });

3. EF Core इस प्रॉपर्टी के साथ एक LINQ एक्सप्रेशन को SQL क्वेरी में बदल सकता है।
सूची लोड करते समय LastName और FirstName द्वारा छँटाई जोड़ें:

 public async Task<IReadOnlyList<Person>> GetList() { return await _context.Persons .OrderBy(p => p.PersonalName.LastName.Value) .ThenBy(p => p.PersonalName.FirstName.Value) .ToListAsync(); }

इस तरह की अभिव्यक्ति को SQL क्वेरी में सही ढंग से परिवर्तित किया जाएगा और सॉर्टिंग SQL सर्वर साइड पर की जाती है, और एप्लिकेशन में नहीं।

बेशक, इसके नुकसान भी हैं।

अशक्त के साथ समस्याएं दूर नहीं हुई हैं;
स्वामित्व वाले प्रकार फ़ील्ड को आसानी से नहीं पढ़ा जा सकता है और उनके पास एक संरक्षित या निजी सेटर होना चाहिए।
स्वामित्व वाले प्रकारों को नियमित इकाई के रूप में लागू किया जाता है, जिसका अर्थ है:
- उनके पास एक पहचानकर्ता है (एक छाया संपत्ति की तरह, यानी यह डोमेन वर्ग में प्रकट नहीं होता है);
- EF Core, स्वामित्व वाले प्रकारों में सभी परिवर्तनों को ट्रैक करता है, बिल्कुल नियमित इकाई के लिए।

एक तरफ, यह बिल्कुल भी नहीं है कि मूल्य वस्तुएं क्या होनी चाहिए। उनके पास कोई पहचानकर्ता नहीं होना चाहिए। VO को परिवर्तनों के लिए ट्रैक नहीं किया जाना चाहिए - क्योंकि वे शुरू में अपरिवर्तनीय हैं, मूल एंटिटी के गुणों को ट्रैक किया जाना चाहिए, लेकिन VO के गुणों को नहीं।

दूसरी ओर, ये कार्यान्वयन विवरण हैं जिन्हें छोड़ा जा सकता है, लेकिन फिर से, मत भूलना। ट्रैकिंग परिवर्तन प्रदर्शन को प्रभावित करता है। यदि यह एकल इकाई के चयन (उदाहरण के लिए, आईडी) या छोटी सूचियों के साथ ध्यान देने योग्य नहीं है, तो "भारी" इकाई (कई वीओ-गुण) की बड़ी सूचियों के नमूने के साथ, ट्रैकिंग की वजह से प्रदर्शन में गिरावट बहुत ही ध्यान देने योग्य होगी।

प्रदर्शन

हमने पता लगाया कि किसी डोमेन और रिपॉजिटरी में वैल्यू ऑब्जेक्ट को कैसे लागू किया जाए। यह सब उपयोग करने का समय है। आइए दो साधारण पृष्ठ बनाएं - सूची व्यक्ति और व्यक्ति को जोड़ने के लिए फॉर्म के साथ।

एक्शन तरीकों के बिना नियंत्रक कोड इस तरह दिखता है:

 public class HomeController : Controller { private readonly IPersons _persons; private readonly UnitOfWork _unitOfWork; public HomeController(IPersons persons, UnitOfWork unitOfWork) { if (persons == null) { throw new ArgumentNullException(nameof(persons)); } if (unitOfWork == null) { throw new ArgumentNullException(nameof(unitOfWork)); } _persons = persons; _unitOfWork = unitOfWork; } // Actions private static PersonModel CreateModel(Person person) { return new PersonModel { FirstName = person.PersonalName.FirstName.Value, LastName = person.PersonalName.LastName.Value, Age = person.Age.Value }; } }

व्यक्ति सूची प्राप्त करने के लिए क्रिया जोड़ें:

 [HttpGet] public async Task<IActionResult> Index() { var persons = await _persons.GetList(); var result = new PersonsListModel { Persons = persons .Select(CreateModel) .ToArray() }; return View(result); }

राय

 @model PersonsListModel @{ ViewData["Title"] = "Persons List"; } <div class="text-center"> <h2 class="display-4">Persons</h2> </div> <table class="table"> <thead> <tr> <td><b>Last name</b></td> <td><b>First name</b></td> <td><b>Age</b></td> </tr> </thead> @foreach (var p in Model.Persons) { <tr> <td>@p.LastName</td> <td>@p.FirstName</td> <td>@p.Age</td> </tr> } </table>

कुछ भी जटिल नहीं है - हमने सूची लोड की, प्रत्येक के लिए एक डेटा-ट्रांसफर ऑब्जेक्ट (पर्सनोडेल) बनाया

व्यक्ति और संबंधित दृश्य के लिए भेजा।

परिणाम

बहुत अधिक दिलचस्प व्यक्ति का जोड़ है:

 [HttpPost] public async Task<IActionResult> AddPerson(PersonModel model) { if (model == null) { return BadRequest(); } if (!Name.IsValid(model.FirstName)) { ModelState.AddModelError(nameof(model.FirstName), "FirstName is invalid"); } if (!Name.IsValid(model.LastName)) { ModelState.AddModelError(nameof(model.LastName), "LastName is invalid"); } if (!Age.IsValid(model.Age)) { ModelState.AddModelError(nameof(model.Age), "Age is invalid"); } if (!ModelState.IsValid) { return View(); } var firstName = new Name(model.FirstName); var lastName = new Name(model.LastName); var person = new Person( new PersonalName(firstName, lastName), new Age(model.Age)); await _persons.Add(person); await _unitOfWork.Commit(); var persons = await _persons.GetList(); var result = new PersonsListModel { Persons = persons .Select(CreateModel) .ToArray() }; return View("Index", result); }

राय

 @model PersonDemo.Models.PersonModel @{ ViewData["Title"] = "Add Person"; } <h2 class="display-4">Add Person</h2> <div class="row"> <div class="col-md-4"> <form asp-action="AddPerson"> <div asp-validation-summary="ModelOnly" class="text-danger"></div> <div class="form-group"> <label asp-for="FirstName" class="control-label"></label> <input asp-for="FirstName" class="form-control" /> <span asp-validation-for="FirstName" class="text-danger"></span> </div> <div class="form-group"> <label asp-for="LastName" class="control-label"></label> <input asp-for="LastName" class="form-control" /> <span asp-validation-for="LastName" class="text-danger"></span> </div> <div class="form-group"> <label asp-for="Age" class="control-label"></label> <input asp-for="Age" class="form-control" /> <span asp-validation-for="Age" class="text-danger"></span> </div> <div class="form-group"> <input type="submit" value="Create" class="btn btn-primary" /> </div> </form> </div> </div> @section Scripts { @{await Html.RenderPartialAsync("_ValidationScriptsPartial");} }

आने वाले डेटा की एक अनिवार्य मान्यता है:

 if (!Name.IsValid(model.FirstName)) { ModelState.AddModelError(nameof(model.FirstName), "FirstName is invalid"); }

यदि ऐसा नहीं किया जाता है, तो गलत मान के साथ VO बनाते समय, एक ArgumentException को फेंक दिया जाएगा (VO कंस्ट्रक्टर्स में गार्ड क्लॉज को याद रखें)। सत्यापन के साथ, उपयोगकर्ता को संदेश भेजना बहुत आसान है कि मूल्यों में से एक गलत है।

परिणाम

यहां आपको एक छोटा सा विषयांतर बनाने की आवश्यकता है - एस्प नेट कोर में डेटा सत्यापन का एक नियमित तरीका है - विशेषताओं का उपयोग करना। लेकिन DDD में, सत्यापन का यह तरीका कई कारणों से सही नहीं है:

सत्यापन तर्क के लिए गुण क्षमताएं पर्याप्त नहीं हो सकती हैं;
किसी भी व्यावसायिक तर्क, जिसमें मानकों को मान्य करने के नियम शामिल हैं, विशेष रूप से डोमेन द्वारा निर्धारित किया गया है। इस पर उनका एकाधिकार है और अन्य सभी परतों को इस पर ध्यान देना चाहिए। विशेषताओं का उपयोग किया जा सकता है, लेकिन आपको उन पर भरोसा नहीं करना चाहिए। यदि विशेषता गलत डेटा को छोड़ देती है, तो VO बनाते समय हमें फिर से एक अपवाद मिलेगा।

AddPerson () पर वापस जाएं। डेटा सत्यापन के बाद, PersonalName, Age और उसके बाद Person बनाए जाते हैं। इसके बाद, ऑब्जेक्ट को रिपॉजिटरी में जोड़ें और परिवर्तनों को सहेजें (कमिट करें)। यह बहुत महत्वपूर्ण है कि EfPersons रिपॉजिटरी में प्रतिबद्ध को लागू नहीं किया गया है। रिपॉजिटरी का कार्य डेटा के साथ कुछ क्रिया करना है, और नहीं। प्रतिबद्ध केवल बाहर से किया जाता है, जब बिल्कुल - प्रोग्रामर तय करता है। अन्यथा, एक स्थिति संभव है जब एक निश्चित व्यापार पुनरावृत्ति के बीच में कोई त्रुटि होती है - कुछ डेटा सहेजे जाते हैं और कुछ नहीं होते हैं। हम "टूटी हुई" स्थिति में डोमेन प्राप्त करते हैं। यदि कमिट बहुत अंत में किया जाता है, तो यदि त्रुटि होती है, तो लेनदेन बस वापस आ जाएगा।

निष्कर्ष

मैंने सामान्य रूप से वैल्यू ऑब्जेक्ट्स के कार्यान्वयन और एंटिटी फ्रेमवर्क कोर में मैपिंग की बारीकियों का उदाहरण दिया। मुझे उम्मीद है कि सामग्री को समझने में उपयोगी होगा कि व्यवहार में डोमेन ड्रिवेन डिज़ाइन के तत्वों को कैसे लागू किया जाए।

पूरा PersonsDemo प्रोजेक्ट सोर्स कोड - GitHub

सामग्री वैकल्पिक (अशक्त) मान ऑब्जेक्ट के साथ बातचीत करने की समस्या का खुलासा नहीं करती है - यदि PersonalName या आयु को व्यक्ति के गुणों की आवश्यकता नहीं थी। मैं इस लेख में इसका वर्णन करना चाहता था, लेकिन यह पहले से ही कुछ अतिभारित था। यदि इस मुद्दे में रुचि है - टिप्पणियों में लिखें, निरंतरता होगी।

विशेष रूप से "सुंदर आर्किटेक्चर" के प्रशंसकों के लिए और विशेष रूप से डोमेन ड्रिवेन डिज़ाइन में, मैं एंटरप्राइज़ शिल्प कौशल संसाधन की अत्यधिक अनुशंसा करता हूं।

आर्किटेक्चर के सही निर्माण और .Net पर कार्यान्वयन उदाहरणों के बारे में कई उपयोगी लेख हैं। कुछ विचारों को वहाँ उधार लिया गया था, सफलतापूर्वक "मुकाबला" परियोजनाओं में लागू किया गया था और इस लेख में आंशिक रूप से परिलक्षित हुआ था।

स्वामित्व प्रकार और मूल्य रूपांतरण के लिए आधिकारिक दस्तावेज का भी उपयोग किया गया था ।

डोमेन ड्रिवेन डिज़ाइन: प्रैक्टिस में वैल्यू ऑब्जेक्ट्स और एंटिटी फ्रेमवर्क कोर