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

package organization

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

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

दूसरे फ़ोल्डर में मैंने सेवा कार्यान्वयन किया है, और जैसा कि मैंने पहले बताया, उत्पाद के व्यावसायिक तर्क के साथ।

क्या यह एक साधारण उपयोग के मामले में हेक्सागोनल आर्किटेक्चर को लागू करने का एक सही तरीका है? यदि नहीं, तो क्यों? मुझे हर कक्षा कहाँ रखनी चाहिए और क्यों? यह वही है जो स्पष्ट नहीं है ...

बहुत मान करना!

1
Toni Montero 6 अप्रैल 2021, 18:33

2 जवाब

सबसे बढ़िया उत्तर

आप अपने कोड को अपनी इच्छानुसार व्यवस्थित करने के लिए पूरी तरह से स्वतंत्र हैं। यह हेक्सागोनल वास्तुकला से संबंधित नहीं है।

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

उदाहरण के लिए, निम्न संरचना होने के बजाय:

controller
    product
    cart
    customer
service
    product
    cart
    customer
repository
    product
    cart
    customer

डीडीडी निम्नलिखित संरचना की सिफारिश करता है:

product
    controller
    service
    repository
cart
    controller
    service
    repository
customer
    controller
    service
    repository

एक बार ऐसा करने के बाद, अगर यह मदद करता है, तो आप हेक्सागोनल आर्किटेक्चर के विभिन्न हिस्सों के लिए इन्हें तीन पैकेजों में लपेट सकते हैं: उपयोगकर्ता पक्ष, व्यावसायिक तर्क और सर्वर पक्ष। यह कुछ ऐसा है जो मैंने अतीत में किया है; यह मुझे विभिन्न परतों को स्पष्ट रखने में मदद करता है।

userside
    product
        controller
    cart
        controller
    customer
        controller
businesslogic
    product
        service
    cart
        service
    customer
        service
serverside
    product
        service
    cart
        repository
    customer
        repository

फिर, आपके पैकेज की संरचना सबसे महत्वपूर्ण अवधारणा नहीं है। हेक्सागोनल वास्तुकला तीन सिद्धांतों पर केंद्रित है:

  • उपयोगकर्ता पक्ष, व्यावसायिक तर्क और सर्वर साइड परतों को स्पष्ट रूप से अलग करें। एक स्पष्ट पैकेज संरचना मदद करती है, लेकिन आप इन परतों को अन्य तरीकों से अलग कर सकते हैं।
  • निर्भरता उपयोगकर्ता पक्ष और सर्वर साइड परतों से व्यावसायिक तर्क तक जाती है। यह व्यावसायिक तर्क में इंटरफेस और एडेप्टर को परिभाषित करके किया जाता है (नीचे देखें)। लक्ष्य यह है कि व्यावसायिक तर्क परत को प्रभावित किए बिना उपयोगकर्ता पक्ष और सर्वर पक्ष में कोड बदला जा सकता है। उदाहरण के लिए, यदि आप अपनी रिपॉजिटरी को MySQL कार्यान्वयन से PostgreSQL कार्यान्वयन (सर्वर साइड लेयर में) में बदलना चाहते हैं, तो यह परिवर्तन आपके व्यावसायिक तर्क को प्रभावित नहीं करना चाहिए: नए कार्यान्वयन के लिए केवल व्यावसायिक तर्क में इंटरफ़ेस का अनुपालन करना आवश्यक है।
  • निर्भरता इंजेक्शन: व्यावसायिक तर्क इंटरफेस (आमतौर पर "पोर्ट" कहा जाता है) और ट्रांसफार्मर ("एडेप्टर") को परिभाषित करता है जिसके साथ उपयोगकर्ता पक्ष और सर्वर साइड परतों को संचार के लिए अनुपालन करना चाहिए।

यह एक बहुत ही डीडीडी उन्मुख वास्तुकला है; विचार यह है कि व्यावसायिक तर्क जितना संभव हो सके डोमेन के करीब रहें, और तकनीकी आवश्यकताओं के बिना मिलावट करें।

2
Chris Neve 8 अप्रैल 2021, 12:05

हेक्सागोनल आर्किटेक्चर हेक्सागोन कोड (व्यावसायिक तर्क) को व्यवस्थित करने के तरीके के बारे में कुछ भी नहीं कहता है। आप जैसा चाहें लागू कर सकते हैं।

इन लेखों पर एक नज़र डालें:

https://jmgarridopaz.github.io/content/articles.html

1
choquero70 7 अप्रैल 2021, 23:09