एमवीसी फ्रेमवर्क में डीडीडी लागू करें-PHP




laravel design-patterns (4)

एमवीसी में मॉडल एक परत है और इसमें सभी डोमेन व्यवसाय तर्क शामिल हैं I
डोमेन संचालित डिजाइन व्यापार तर्क में विभिन्न बिल्डिंग ब्लॉकों में विभाजित किया जा सकता है जैसे कि

डोमेन चालित डिजाइन डोमेन मॉडल में है

एक डोमेन मॉडल एक ऐसी प्रणाली है जिसमें ज्ञान, प्रभाव या गतिविधि (एक डोमेन) के क्षेत्र के चयनित पहलुओं का वर्णन किया गया है। उस मॉडल का उपयोग उस डोमेन से संबंधित समस्याओं को हल करने के लिए किया जा सकता है

डेवलपर ने डोमेन प्रेरित डिजाइन को पढ़ा है, या डॉक्ट्रिन 2 या हाइबरनेट का इस्तेमाल किया है, आमतौर पर डीडीडी। में डोमेन मॉडल पर बेहतर ध्यान केंद्रित किया जाता है। एमवीसी फ्रेमवर्क मॉडल परत डीडीडी में डोमेन मॉडल के साथ ओवरलैप है। इसका मतलब है कि हम मॉडल फ़ोल्डर में मॉडल मॉडल को लागू कर सकते हैं एमवीसी चौखटे

इस प्रकार एक कार्यान्वयन नीचे दिखाया गया है। दिखाता है कि कैसे मॉडल फ़ोल्डर संरचना है

   Model(this can model or domain)
   | 
   |----Entities
   |    |---BlogPost.php
   |    |---Comment.php
   |    |---User.php
   | 
   |----Repositories
   |    |---BlogPostRepository.php
   |    |---CommentRepository.php
   |    |---UserRepository.php
   | 
   |----Services
   |    |---UserService.php
   | 
   |----factories
   |    |---userfactory.php
   | 
   |----dataMappers
   |    |---userDataMapper.php // this inherit from Eloquent model
   | 
   |----ValueObject


  • मैं जानना चाहता हूं कि मेरी पहली धारणा (एमवीसी चौखटे में मॉडल फ़ोल्डर में डोमेन मॉडल लागू कर सकते हैं) सही है?
  • क्या यह सही डिजाइन है कि डीडीडी में सभी बिल्डिंग ब्लॉक्स मॉडल फ़ोल्डर में लागू होते हैं (जैसा कि ऊपर दिखाया गया है) जैसे संस्थाएं, सेवा, रिपॉजिटरी
  • या इस कार्यान्वयन के बारे में आपके पास कोई अन्य सुझाव
  • अगर यह गलत है तो एमडीसी चौखटे में संस्थाओं, सेवाओं, रिपॉजिटरी जैसे डीडीडी के निर्माण ब्लॉकों को लागू करने का सही तरीका क्या है

एमवीसी में मॉडल एक परत है और इसमें सभी डोमेन व्यवसाय तर्क शामिल हैं I

मुझे संदेह है कि एमवीसी पैटर्न ही डोमेन के बारे में कुछ विशेष घोषित करता है। यह मॉडल को प्रॉपर्टी के एक बैग के रूप में चलाता है और इसकी परवाह नहीं है कि यह कैसे बनाया गया था और यह कैसे अपने इनवेरियंट्स की रक्षा करता है।

उसी समय प्याज वास्तुकला में कहा गया है कि डोमेन से बाहर अनुप्रयोग सेवा (जो कि एमवीसी फ्रेमवर्क है) को अलग करने के लिए महत्वपूर्ण है। इसलिए मैं डोमेन परत डालना चाहूंगा जिसमें एंटिटीज , वैल ऑब्जेक्ट्स , डोमेन इवेंट्स और समुच्चय एक अलग मॉड्यूल या एक शीर्ष-स्तरीय फ़ोल्डर के लिए होता है।

एमवीसी सामान से अलग-अलग डोमेन रखने के लिए एक और कारण यह है कि इससे आप कई बाध्य संदर्भों को प्रबंधित कर सकते हैं, क्योंकि प्रत्येक प्रसंग को अपने मॉड्यूल / फ़ोल्डर की आवश्यकता है

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


आपकी पहली धारणा सही नहीं है, एमवीसी वास्तव में डीडीडी के साथ फिट नहीं है, एक बेहतर तरीका सीक्यूआरएस पैटर्न का उपयोग करना होगा

आपकी दूसरी धारणा भी सही नहीं है, बिल्डिंग ब्लॉक डोमेन मॉडल फ़ोल्डर में नहीं हैं, वास्तव में, यहां आपकी परियोजना के लिए एक अच्छी संरचना है:

ProjectName/
    Application/
        Blog/
            Command/
                CommentToBlogPostCommand.php
                ChangeCommentContent.php
                DescribeBlogPostCommand.php
                NewBlogPostCommand.php
                ...
            Data/
                BlogPostData.php
                BlogPostCommentsData.php (POPO containing BlogPost infos and the comments array)
                CommentData.php (Single comment infos)
            BlogPostApplicationService.php
            BlogPostQueryService.php
            CommentApplicationService.php
            CommentQueryService.php
        Identity/
            Command/
                AuthenticateUserCommand.php
                ChangeEmailAddressCommand.php
                ChangeUserPasswordCommand.php
                ChangeUserPersonalNameCommand.php
                DefineUserEnablementCommand.php
                RegisterUserCommand.php

            UserApplicationService.php (this defines the actions that can be done by your application related to user domain, injected in presentation layer responding to user events)
            UserQueryService.php (this will usually be injected in your presentation layer)
    Domain/
        Model/
            Blog/
                BlogPost.php
                BlogPostClosed.php (this could be a list of possible events)
                BlogPostDescriptionChanged.php
                BlogPostModeratorChanged.php
                BlogPostReopened.php
                BlogPostStarted.php
                BlogPostRepository.php (interface)
                Comment.php (this is an Entity, or Aggregate Root)
                CommentContentAltered.php (this could be an event)
                CommentAuthor.php (this could be a ValueObject, containing the username)
                CommentRepository.php (interface)
                CommentedToBlogPost.php (this could be another event when adding a comment to a blogpost)
                ...
            Identity/
                ContactInformation.php (VO or Person)
                Enablement.php (VO of User)
                EmailAddress.php (VO of ContactInformation)
                FullName.php (VO or Person)
                Person.php (ValueObject of User)
                User.php (constructor visibility might be package-protected)
                UserFactory.php
                UserRepository.php (this is an interface)
                UserService.php (this is a domain service)
    Infrastructure/
        Persistence/
            LavarelBlogPostRepository.php (this implements BlogPostRepository)
            LavarelCommentRepository.php (this implements CommentRepository)
            LavarelUserRepository.php (this implements UserRepository)
    Interfaces/
        ...

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

ध्यान दें टिप्पणीअधिकारी वर्ग एक मान ऑब्जेक्ट हो सकता है, जिसमें डेटाबेस का उपयोगकर्ता आईडी नहीं है लेकिन एक अनन्य उपयोगकर्ता नाम है चूंकि उपयोगकर्ता कुल रूट किसी अन्य पैकेज से है: जो डोमेन पॉइंटऑफ दृश्य से समझ में आता है। हम इसे एक पहचान (या उपयोगकर्ता नाम) कह सकते हैं यह आदर्श उपयोगकर्ता तालिका के एक अद्वितीय कॉलम के लिए मैप किया जाएगा, लेकिन टिप्पणी तालिका के एक अनुक्रमित मान होगा।

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

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

एप्लिकेशन परत सुरक्षा, स्पैन लेनदेन संबंधी संदर्भ प्रबंधन और उच्च स्तरीय इवेंट लॉग इन करने के लिए जिम्मेदार है।

यदि आपको कुछ स्पष्टीकरण की आवश्यकता है तो मैं आपको कक्षाओं के शिष्टाचार के बारे में अधिक जानकारी प्रदान कर सकता हूं इसके लिए इसके लिए कुछ बुनियादी ढांचे या एक समर्थन ढांचे की आवश्यकता हो सकती है, जिससे मैं यह सोच रहा हूं:

  • निर्भरता अन्तःक्षेपण,
  • इवेंट डिस्पैचर पात्रता में उपलब्ध है,
  • किसी प्रकार की घटना बस अगर आप इन घटनाओं का उपभोग करने की योजना बनाते हैं

मैं मॉडल को एमवीसी में विचारमण्डल और कमांड का संयोजन मानता हूं। आवक अनुरोधों को उन आज्ञाओं के लिए मैप किया जाता है जो एक "लिखना" परत पर प्रेषित हो जाएंगे जो उचित समेकन को प्राप्त करेगा और उस पर उपयुक्त विधि कहलाता है, फिर लेनदेन को कम करता है

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


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

app/
    ProjectName/
        Core/
            Application/
            Domain/
            Infrastructure/
        User/
            Application/
                Services/
                    CreateUserService.php
                    FindUserService.php
                    UpdateUserService.php
            Domain/
                Role.php
                RoleDAO.php
                User.php
                UserDAO.php
                UserNotCreated.php
                UserNotFound.php
                UserNotUpdated.php
                UserWasCreated.php
                UserWasUpdated.php
            Infrastructure/
                EloquentRoleDAO.php
                EloquentUserDAO.php

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

अपने खुद के आवेदन की संकर प्रकृति (मैं ORM- निर्भर DAO / संस्थाओं, लेनदेन लिपियों का उपयोग कर रहा हूं, और केवल कुछ विचलनों को नाम देने के लिए वैल्यू ऑब्जेक्ट से बचने) को छोड़कर, यह अभी भी एक संभावित डीडीडी निर्देशिका एक एमवीसी एप के अंदर संरचना





domain-driven-design