Golang Package Structure Explained in 7 Minutes

Golang Package Structure Explained
In today's Golang video, we will talk about the Package Structure in Go. We will go through the types of packages, package naming, package scope, how to structure packages, and everything you need to know about Package Structure in Go programming language. Enjoy!
--
Golang Dojo is all about becoming Golang Ninjas together. You can expect all kinds of Golang tutorials, news, tips & tricks, and my daily struggles as a Golang developer. Make sure to subscribe if you look forward to such content!
Get Your Golang Cheat Sheet! - golangdojo.com/cheatsheet
Git repos & notes - golangdojo.com/resources
Golang Project Structure - • Playlist
--
#golang #goprogramming #golangdojo

[@GolangDojo]

📝Get your *FREE Golang Cheat Sheet* - golangdojo.com/cheatsheet

[@itsabzer8431]

cheat sheet doest get sent when input my name and email. is the link no longer working? I've tried 3 of my emails

[@ericzorn3735]

I would love to see domain driven design architecture. I really have been a fan of CQRS with event sourcing and would love to see the implementation in go

[@HAL-9000-]

☝️

[@GolangDojo]

Thank you for the suggestion!

[@rafabil1096]

☝️

[@frankfix247]

Just to mention... 1. Packages/directories should not use plural naming. 2. Executable(s) should mainly be placed in the cmd/ directory.

[@vitorrocha9225]

Bro, you are building a great community, keep goin on. There's so many videos to do

[@churraskindequeijo8418]

I would love to see more content on project structure, this video helped me alot, I was doing a ton of shit wrong lol thx

[@dancollings]

More designs please 🙏. Keep up the great work. Great content.

[@mystiqkc]

Excellent video! Thanks for these.

[@nickolas1386]

I’d like to see how you’d recommend organizing a larger MVC design with database. This video was great!

[@padawanpath]

great video mate, really clear and to the point

[@alunoazul]

I would... REALLY REALLY REALLY like to see a video about more complex project structures. Please! Please!

[@slimbron9489]

Excellent content ⭐, thanks for sharing 👍, it would be nice to see more content on architecture of complex projects in golang.

[@farzadmf]

Oh no! Don't remove your Ninja intro, I LOVED It 🙁

[@GolangDojo]

Coming right back :)

[@farzadmf]

Great! 😆

[@gideonfelt2819]

I'd love some videos on common design patterns!

[@GolangDojo]

Coming soon!

[@ant1fact]

Thank you for this, Dolan Gojo

[@alekseytrump1586]

Thanks. Go next video, on design and hard architecture application :-)

[@SirMo]

This tutorial is missing the biggest question I had. And that was the recommended way to import these packages. Oh well.

[@flexairz]

I would like to see more of the complex project structures in Go. BTW: the new video format is less personal.. I liked the old format better..

[@GolangDojo]

Thank you for the suggestion!

[@carlosdelgado5632]

If you could go through each one with examples it would be awesome 👏

[@GolangDojo]

In the pipeline

[@hoxorious]

Great video as always. 6:21 yes of course we want! 🤩

[@GolangDojo]

You got it!

[@BrunoDrugowick]

Your videos are good, keep it up! :) I'd do a bit different, tbh: packages under pkg, with the structure you suggested probably, and main(s) under cmd.

[@mouhannadal-hmedi1501]

amazing!!! thanks

[@krige]

5:00 You are structuring your packages by type. Package-by-type only works on small-scale projects. Package-by-feature is superior in the majority of cases as it allows to play with the components' scope. We can use the access modifiers to enforce Law of Demeter and the dependency inversion for integrations or/and extensions. Other reasons are: easier code navigation, a higher level of abstraction, minimize scopes (bounding contexts), vertical modularization.

[@Rundik]

Packages should be small and many, but you shouldn't use camel case. That's like impossible, you can't get many of short names also being descriptive

[@a4e69636b]

Thank you for this video. I would like to see a MVC video please.

[@sarthaktiwari8515]

great video, nicely explained :D

[@GolangDojo]

Glad you liked it :)

[@angelkarki2963]

have you made anything about MVC package structure brother?

[@amitsharma928]

Nicely explained 👍 Thanks

[@GolangDojo]

Welcome!

[@regexPattern]

Btw, a vim tip for when you were talking about block scopes: you can select all the inner elements of the current scope with vi{

[@GolangDojo]

I'm still a noob in vim :)

[@RootsterAnon]

@@GolangDojo @ThePrimeagean will help you. Watch his vim 6 part tutorial. It's everything I ever wanted.

[@kaushik5055]

👍

[@manuelcarbajal7610]

Please! Let's dive into those other topics! :D This part of Go is one I find a little confusing :P

[@GolangDojo]

In the pipeline!

[@sasipraveen5257]

Finally Vim

[@GolangDojo]

;)

[@budi0580]

DDD project structure pls..

[@user-hd8tg4em2n]

Nice introduction, but what if we had a complex situation where a package relies on another package but also the package it calls from? for eg. We have Server, Client and Routine packages, in client we have a client struct, and in routines we want to run a routine with that client type from client package as a parameter, how does this work? If we try import client into routines, we get a import cycle. client relies on routines to run the routine and routines relies on client to access the type. You could put the client struct into it's own package and import that where you need it, but what if client has functions tied to it? This won't work because it's not a local type of the client package so we can't add functions to the client struct instantiation.

[@GolangDojo]

Circular reference doesn't work here as I briefly mentioned. The actual organization depends the specifics, but perhaps you'd need to duplicate the routines for the client, or utilize interfaces to make the routine or the client more generic. Also, I'm not entirely sure what the routine you refer to is about.

[@user-hd8tg4em2n]

@@GolangDojo I've been doing a lot of reading and it seems interfaces are a way to achieve this along with a separate package just for types, but now I run into issues of the type that's local to client not being the type in routines that we import from the types package.

[@mahendranath2504]

DDD, please 🙏

[@mr.k8660]

You didn't show code 🙄

[@sydpao2224]

Goland vs IntelliJ (go plugin) vs vscode

[@TJ-wc3iq]

No-no! Please follow "Package Driven Development" instead of anything from Java, C# or even Node ecosystem. Pleeeeease 😋Keep Go clean, simple, and concise.

[@samuelchinonsoarchibong1477]

You skipped the important part of executing the packages

[@motdde]

Like a noob 👀

[@matrixnorm6672]

narrator is drunk

[@OddBallTrails]

😂😂😂