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

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

मैं इस पोस्ट को 3 संदर्भों में विभाजित करूंगा और फिर दिखाऊंगा कि परियोजना में इन संदर्भों का मिश्रण कैसे निकला।

पहला सन्दर्भ

एक जटिल प्रणाली जो काम करती है वह हमेशा काम करने वाली एक सरल प्रणाली से विकसित होती है।
-- गैल का नियम

छोटे अनुप्रयोगों के लिए, परियोजना संरचना सरल होनी चाहिए।

दूसरा सन्दर्भ

"समुदाय" ने गो पारिस्थितिकी तंत्र में आम ऐतिहासिक और उभरते डिज़ाइन लेआउट पैटर्न के एक सेट का सर्वेक्षण किया। इस सर्वेक्षण में बहुत सी अच्छी चीजें हैं, लेकिन जिस चीज ने मेरा ध्यान खींचा वह /cmd और /आंतरिक फ़ोल्डर थे .

/सीएमडी

इस परियोजना के लिए मुख्य अनुप्रयोग।
प्रत्येक एप्लिकेशन के लिए निर्देशिका का नाम उस निष्पादन योग्य के नाम से मेल खाना चाहिए जिसे आप रखना चाहते हैं (उदाहरण के लिए /cmd/myapp)।

/आंतरिक

निजी एप्लिकेशन और लाइब्रेरी कोड। यह वह कोड है जिसे आप नहीं चाहते कि अन्य लोग अपने एप्लिकेशन या लाइब्रेरी में आयात करें। ध्यान दें कि यह लेआउट पैटर्न गो कंपाइलर द्वारा ही लगाया गया है।

तीसरा सन्दर्भ

आर्किटेक्चर जो वास्तव में मूल्य प्रदान करने वाली चीज़ से "विवरण" को बेहतर ढंग से अलग करता है।

परिणाम

एक साधारण एप्लिकेशन के लिए मैं इसे सरल रखने की कोशिश करता हूं, हालांकि, जब दायरा थोड़ा बड़ा हो जाता है, तो मैं "कोर"/डोमेन क्या है और डिटेल/इंफ्रास्ट्रक्चर क्या है, के बीच थोड़ा अंतर करने की कोशिश करता हूं।

ध्यान दें कि cmd में मेरे पास टुटिपेट फ़ोल्डर नहीं है, जैसा कि संदर्भ परियोजना से पता चलता है। सबसे पहले मैंने सुझाए गए पैटर्न का उपयोग करने की कोशिश की, लेकिन चूंकि यह एपीआई पहले से ही एक कमांड लाइन इंटरफेस और टेराफॉर्म के लिए एक प्रदाता के साथ सामने आया था, इसलिए मैंने इसे इस तरह छोड़ने का फैसला किया।

कोर पर त्वरित ज़ूम करें। मैं यहां सरलीकृत रहने का प्रयास करता हूं और फ़ोल्डर्स नहीं बनाने का प्रयास करता हूं। मैं बाहरी दुनिया (main.go) के साथ संपर्क का केवल 1 बिंदु बनाए रखता हूं, जो कुछ भी सामान्यीकृत होता है उसकी अपनी फ़ाइल होती है और जो कुछ नहीं होता वह अपने संदर्भ में सरल रहता है।

tuttipet.New (संक्षिप्त, संक्षिप्त और विचारोत्तेजक) के साथ "गंदी" परत यूज़केस के साथ इंटरैक्ट कर सकती है (मुझे इंटरैक्टर की तुलना में यूज़केस शब्द को आत्मसात करना आसान लगता है)

विवरण पर त्वरित ज़ूम करें। यहां केवल वे उपकरण हैं जिनके द्वारा डोमेन अपनी सफलता प्राप्त करेगा।

निष्कर्ष

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

सारांश, जब भी संभव हो इसे सरल रखने की कोशिश कर रहा हूं और यदि यह बहुत जटिल हो जाता है... तो मैं ड्राइंग बोर्ड पर वापस जाऊंगा।

अन्य संदर्भ

https://dev.to/booscaaa/implementando-clean-architecture-com-golang-4n0a
https://github.com/golang-standards/project-layout
https://blog.boot.dev/golang/golang-project-structure/
https://github.com/bnkamaresh/goapp
https://www.wolfe.id.au/2020/03/10/how-do-i-structure-my-go-project/
https://blog.logrocket.com/flat-structure-vs-layered-architecture-structuring-your-go-app/
https://developer20.com/how-to-structure-go-code/
https://dev.to/jinxankit/go-project-structure-and-guidelines-4ccm
https://github.com/bxcodec/go-clean-arch
https://golangexample.com/example-go-clean-architecture-folder-pattern/
https://www.calhoun.io/flat-application-structure/
https://go.dev/doc/effective_go#names
https://go.dev/blog/package-names

मूल पोस्ट: https://medium.com/@espigah/go-layout-do-projeto-18aacce8089d