لقد بدأت البرمجة باستخدام Golang بشكل حقيقي هذا العام (2022)، والشيء الذي فعلته على الفور هو البحث عن مراجع حول أفضل طريقة لتطوير هيكل المشروع الخاص بي. ستكون هذه المقالة مجرد واحدة من العديد من المقالات الأخرى التي تتحدث عن نفس الموضوع، وربما لهذا السبب قررت كتابتها.

أولاً، إن golang مختلف تمامًا بالفعل في الطريقة التي يتعامل بها مع المجلدات/الحزم، وللتحسين، فهو يتمتع بجوهر عنيد جدًا، حيث توضح العديد من المستندات الرسمية ما هي الطريقة "goway" لفعل شيء ما (كاملة) ليس أنا ألمس)، ومع ذلك، في الطريقة التي تنظم بها ملفاتك ومجلداتك، لا يوجد اتجاه حقًا، لذلك يقدم الجميع تفسيرهم الخاص للعالم لهذا الجزء.

سأقسم هذا المنشور إلى 3 مراجع ثم أوضح كيف تحول مزيج هذه المراجع في المشروع.

المرجع الأول

النظام المعقد الذي يعمل بشكل ثابت تطور من نظام بسيط ناجح.
-- قانون غال

بالنسبة للتطبيقات الصغيرة، يجب أن يكون هيكل المشروع بسيطًا.

المرجع الثاني

أجرى "المجتمع" دراسة استقصائية لمجموعة من أنماط تخطيط التصميم التاريخية والناشئة الشائعة في نظام Go البيئي. هناك الكثير من الأشياء الرائعة في هذا الاستطلاع، ولكن ما لفت انتباهي هو المجلدات /cmd و/الداخلية

.

/كمد

التطبيقات الرئيسية لهذا المشروع.
يجب أن يتطابق اسم الدليل لكل تطبيق مع اسم الملف القابل للتنفيذ الذي تريد الحصول عليه (على سبيل المثال /cmd/myapp).

/داخلي

التطبيق الخاص وكود المكتبة. هذا هو الرمز الذي لا تريد أن يستورده الآخرون إلى تطبيقاتهم أو مكتباتهم. لاحظ أن نمط التخطيط هذا يتم فرضه بواسطة مترجم Go نفسه.

المرجع الثالث

المعماريات التي تفصل "التفاصيل" بشكل أفضل عما يقدم القيمة حقًا.

نتيجة

بالنسبة لتطبيق بسيط، أحاول أن أبقيه بسيطًا، ومع ذلك، عندما يصبح النطاق أكبر قليلاً، أحاول التمييز قليلاً بين ما هو "الأساسي"/المجال وما هو التفاصيل/البنية التحتية.

لاحظ أنه في

cmd

ليس لدي مجلد tuttipet، كما يقترح المشروع المرجعي. في البداية حاولت استخدام النمط المقترح، ولكن بما أن واجهة برمجة التطبيقات هذه قد ظهرت بالفعل مع واجهة سطر أوامر وموفر لـ terraform، فقد قررت ترك الأمر بهذه الطريقة.

قم بتكبير الصورة الأساسية بسرعة. أحاول أن أكون مبسطًا هنا وألا أقوم بإنشاء مجلدات. أحتفظ بنقطة اتصال واحدة فقط مع العالم الخارجي (main.go)، كل ما يتم تعميمه له ملف خاص به، وما لا يتم تعميمه يبقى ضمن سياقه، بكل بساطة.

قم بتكبير التفاصيل بسرعة. وإليك ببساطة الأدوات التي سيحقق المجال من خلالها نجاحه. خاتمة

ما زلت ضعيفًا في المسار الذي يقدمه Golang، وما زلت أحاول معرفة ما يمكن فعله به، ومع ذلك، على الرغم من أنني لا أحب طريقة Go في القيام ببعض الأشياء، فقد ثبت أنها مفيدة تمامًا بسيطة وقوية.

الملخص، محاولة إبقاء الأمر بسيطًا قدر الإمكان، وإذا أصبح الأمر معقدًا للغاية... سأعود إلى لوحة الرسم.

مراجع أخرى

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/bnkamalesh/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/efficiency_go#names
https://go.dev/blog/package-names

المنشور الأصلي: https://medium.com/@espigah/go-layout-do-projeto-18aacce8089d