Show HN: We wrote a book about building business applications in Go

This page summarizes the projects mentioned and recommended in the original post on news.ycombinator.com

Our great sponsors
  • Scout APM - Less time debugging, more time building
  • OPS - Build and Run Open Source Unikernels
  • SonarLint - Deliver Cleaner and Safer Code - Right in Your IDE of Choice!
  • GitHub repo wild-workouts-go-ddd-example

    Go DDD example application. Complete project to show how to apply DDD, Clean Architecture, and CQRS by practical refactoring.

    Here is example code and blog series for a step-by-step DDD-based refactoring of an existing app. Don't know if they are the same as what's used in the book, but found them quite interesting.

    https://github.com/ThreeDotsLabs/wild-workouts-go-ddd-exampl...

  • Here is example code and blog series for a step-by-step DDD-based refactoring of an existing app. Don't know if they are the same as what's used in the book, but found them quite interesting.

    https://github.com/ThreeDotsLabs/wild-workouts-go-ddd-exampl...

  • Scout APM

    Less time debugging, more time building. Scout APM allows you to find and fix performance issues with no hassle. Now with error monitoring and external services monitoring, Scout is a developer's best friend when it comes to application development.

  • GitHub repo pandoc

    Universal markup converter

    Thanks for the tip! I think we already use xelatex, as the book is created with pandoc (https://pandoc.org/).

  • GitHub repo go-kit

    A standard library for microservices.

    Thanks for mentioning this experience -- I was really excited about Go early on but went with other languages after a while so didn't make any huge projects with it (and definitely not at a large employer/go shop).

    Did you have to do a lot of stuff that is DDD-related? Like building out abstractions for adapters and connection points, or did you use libraries that did that part for you mostly? I know of some stuff out there like go kit[0] which is quite pragmatic and does some of the 80% use-cases (serialization, transports, etc) DDD stuff for you.

    I think for the most part it's rare to actually need to write a lot of your own DDD pieces for CRUD-y apps, and the parts where the complexity would be worth it are often already done for you by the libraries/frameworks used.

    [0]: https://gokit.io/

  • GitHub repo watermill

    Building event-driven applications the easy way in Go.

    > While protocols in Go are great (one of the very many breaths of fresh air that Go provided), operations on data structures without generics does not seem like a good time. Does everyone get around the lack of generics by making most generic-looking operations slightly-specialized structs and some interface composition?

    When it comes to domain code - probably when you are starting to think about generics that's a bad sign. Probably you are trying to make it overcomplicated. Domain code should stay simple and interfaces should be enough to handle it.

    But when it comes to libraries the situation is totally different. One of the example is https://watermill.io library (that we are authors of BTW). Generics could give some nice simplifications.

    It's also a case for event-sourcing library that we are using in the company where we are working on now. But You can still do a lot with interface{} and reflection. But it's not perfect and generate a lot of boilerplate.

    The third example is a decorator pattern. You can't create generic decorator without code generation. It is of course some sort of the solution, but it's not trivial to implement.

  • GitHub repo wire

    Compile-time Dependency Injection for Go

    Take a look at the major DI frameworks for Go, Wire [0] and FX [1]. They just plumb the gaps between methods that return types and methods that want them. Although technically they work for concrete types, 99% of the time it's going to be an interface, so that you can substitute a mock for testing.

    Prior to DI frameworks we used global variables, often initialized in a package's init() method.

    >The desire to do this reflects a misunderstanding of interfaces.

    Generally you have a few layers: gRPC/HTTP/Kafka handler, business logic, and database or external service access. Layers are unit tested individually against mocks of the layers below. Because you're going to inject a mock, you can't depend on a concrete type, so you depend on an interface. Often when you're developing you want to know what the concrete implementation of a lower layer does, so it's useful to have "go-to-definition" see through the interface declaration to its implementations.

    I think the implicit satisfaction of interfaces is very cool and I wish I had it in every language. I wouldn't give it up just to simplify the IDE's job. But the IDE having this functionality does matter.

    [0] https://github.com/google/wire

    [1] https://github.com/uber-go/fx

  • GitHub repo fx

    A dependency injection based application framework for Go. (by uber-go)

    Take a look at the major DI frameworks for Go, Wire [0] and FX [1]. They just plumb the gaps between methods that return types and methods that want them. Although technically they work for concrete types, 99% of the time it's going to be an interface, so that you can substitute a mock for testing.

    Prior to DI frameworks we used global variables, often initialized in a package's init() method.

    >The desire to do this reflects a misunderstanding of interfaces.

    Generally you have a few layers: gRPC/HTTP/Kafka handler, business logic, and database or external service access. Layers are unit tested individually against mocks of the layers below. Because you're going to inject a mock, you can't depend on a concrete type, so you depend on an interface. Often when you're developing you want to know what the concrete implementation of a lower layer does, so it's useful to have "go-to-definition" see through the interface declaration to its implementations.

    I think the implicit satisfaction of interfaces is very cool and I wish I had it in every language. I wouldn't give it up just to simplify the IDE's job. But the IDE having this functionality does matter.

    [0] https://github.com/google/wire

    [1] https://github.com/uber-go/fx

  • OPS

    OPS - Build and Run Open Source Unikernels. Quickly and easily build and deploy open source unikernels in tens of seconds. Deploy in any language to any cloud.

NOTE: The number of mentions on this list indicates mentions on common posts plus user suggested alternatives. Hence, a higher number means a more popular project.

Suggest a related project

Related posts