todo-api-microservice-example VS go-structure-examples

Hello guys im a self teach coder. im working with golang atm because this great project speed up my learning curve: https://github.com/MarioCarrion/todo-api-microservice-example

With that being said, if you're looking for something friendlier, I share my own educational repo, still a WIP but it should help you with the basics.

internal/tools and

You are going to need to add a domain package where the Beer type and all the logic associated to that type is defined to avoid the cyclical dependency. I typically follow this approach by using internal as the domain package that then other packages like services, data stores or transport use.

Here's my approach; a few worth-mentioning packages in there: * service defines the use cases, it's a glue between the domain model and repositories. * rest defines the http handlers uses the service types via dependency injection (see main.go) * postgresql concrete repository example (there are other implementations for other data stores like kafka, redis, etcetera.

Other redditors mentioned some good resources, I'm going to shamelessly plug mine as well; either way after you are done with whatever tutorial you use I recommend you to look at the Exposure Notifications Server, reading the source code should help you learn other best practices.

One word of advise I can give you is that building a production-grade microservice in Go takes a bit; not because of the language but because you have consider the tradeoffs when choosing different packages to connect everything to make it work (because there's no Django, Ruby on Rails or Spring), I have an educational repository (still work in progress) trying to describe what I've learned from the last 5 years after successfully deploying multiple services to production where multiple engineers contribute and collaborate together; perhaps that could help you.

With all of that being said I have an educational repository demonstrating this structure, I've been using it in real life for about 5 years already and I've successfully delivered services to production multiple times where multiple engineers contribute and collaborate together.

You may want to checkout the "Exposure Notifications Server" project; I also have a similar (educational) project that uses the Repository Pattern.

I have a question, I am trying out hexagonal architecture for one of my projects trying to follow this repository example and I ran into a slight problem.

Just fyi, that repo is NOT considered standard, and in fact, is often advised against. The structure of your code should depend on its complexity and how interoperable with other projects you need/would like it to be. I suggest watching this talk on structuring your code and taking a look at this companion repo to decide which will be the best way to structure your code, depending on your needs

Kat Zien's excellent talk, presentation and code samples can be found here.

Thanks for the video, I'll take a look at it. And I checked the repo, I liked how the new is structured: https://github.com/katzien/go-structure-examples/tree/master/new

So here’s where I normally tell people to start off: check out this video and this repo in regards to the main 6 ways of architecting your Go applications.

Watch this and give this repo a look.

Am I completely fumbling it by approaching this the wrong way & if so what should I do differently? I have searched a few repos like this which redefines the same entity in multiple places which I feel is a violation of some sort, and this which the author had to resort to moving some files outside to overcome a circular dependency (see comments inside their handling.go file).

Really surprised I haven’t seen katzien/go-structure-example and her GopherCon 2018 talk about structuring your Go projects mentioned yet

Let's agree to leave the MVC model for OO languages. A better architecture would be something like katzien/go-structure-examples