Best Practices for Structuring Large Go Projects?

Getting Help
1

Hey Gophers! :waving_hand:

I’m currently working on a fairly large Go project, and as the codebase grows, I’m struggling with maintaining a clean and scalable structure. I’ve come across different approaches like domain-driven design (DDD), layered architecture, and package-by-feature, but I’m unsure which one fits best for a Go application.

Here are a few questions I have:

  1. Project Structure – How do you organize your Go projects? Do you follow a standard convention or a custom approach?
  2. Monolith vs. Microservices – At what point should one consider breaking a monolithic Go app into microservices?
  3. Managing Dependencies – What are your go-to tools for handling dependencies and ensuring version consistency?

Additionally, while learning Tableau tutorial for data visualization, I’m considering integrating Go for backend processing. Any insights on best practices for connecting Go with Tableau?

best regards
Cheers! :rocket:

2

When a routine is responsible for one thing only, it is time to use micro service IMO.
Single Responsibility Principle (SRP)

I have right now only 2 micro services (API and Auth) and are planning to use it more in the future. Harder to setup, but easier to maintain is my experience.

3
  • There is no one-size-fits-all structure. Each project requires thoughtful consideration of its specific needs. I recently attended a presentation by an Ardan Labs representative discussing Domain-Driven Design, who emphasized that project structure should vary based on project requirements and team size. Ensure your chosen structure aligns with your specific goals and context.
  • For applications running on the same server, a single binary approach is appropriate. However, I believe there may be a misconception in the discussion. The fundamental consideration is whether to implement a monolithic or distributed system architecture.
  • I prioritize maintaining a minimal dependency footprint. It’s important to note that version consistency isn’t the critical factor—data consistency is what truly matters for system integrity.

And no tips considering Go for Tableau, whatever this is. Data is just data. always. :slight_smile: