16 ms·

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

269 points by roblaszczak 5y ago

marsven_422 5y ago
It's funny to see "the real devs" rediscover the reasons why "fizzbuzz corporate" looks like it does.
bovermyer 5y ago
Love this! Hey, one little tip. I see you're using LaTeX for the book. If you switch to xelatex to compile it, you can use your own fonts, like this: % Set the typeface to use \usepackage{fontspec} \setmainfont{Libre Baskerville} And the compile command: xelatex mybook.tex
- m110 5y ago
  Thanks for the tip! I think we already use xelatex, as the book is created with pandoc (https://pandoc.org/ https://pandoc.org/).
rapnie 5y ago
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-example https://github.com/ThreeDotsLabs/wild-workouts-go-ddd-exampl...
- m110 5y ago
  Hey, one of the authors here. The example is exactly what we base the book on. The chapters go through refactoring of this app.
domano 5y ago
I signed up for the newsletter but got no link to the book so far.
- roblaszczak 5y ago
  Hey, unfortunately our e-mail automation is a bit slow. It should arrive to your mailbox within couple minutes :) I'll add information to subscribe confirmation page about the delay.
  - domano 5y ago
    Yes it arrived, was too impatient :) Thank you
  - deleted 5y ago
    [deleted]
hardwaresofton 5y ago
So I think DDD is basically one of the best pattern that has ever been discovered for developing good software (thinking of it along with gangof4, SOLID, etc). There's a lot of cruft around it and consultants looking to over-complicate it for the sake of getting hired, but viewed simply it's mostly about abstraction at conceptual boundaries -- very hard to be against that on most large projects. That said, can someone weigh in on how it is building large "enterprise-grade" applications in Go 1.x given how (purposefully) constrained the type system in Go is? 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?
- llimllib 5y ago
  I built a large enterprise website in go, and I can say that I barely ever even had to consider the lack of generics. Occasional slightly annoying interface shenanigans and mild interface hackery, but nothing significant at all.
  - hardwaresofton 5y ago
    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/ https://gokit.io/
    - llimllib 5y ago
      I’m not the authors and don’t even really know what ddd means, sorry
moksly 5y ago
Aren’t the first 3 or 4 chapters basically what you can find in Google’s own cloud toturials? Why does the domain-driven-design chapter come after you’ve tied the reader into GCP? I can’t think of a single enterprise business domain where that would make sense from a European GDPR driven perspective. Why do you think you can cover that many topics in a single book? I mean, part of the reason Clean Code is well liked is because it covers one topic in depth, rather than covering a bunch of different topics without ever giving the reader anything of value on any of them. Have you considered going the TDD GOAT book route of earning sales? I’m really sorry that I’m so negative, but your “contents” read like every terrible tech-book I’ve ever opened. Good luck though.
- m110 5y ago
  Hey, these are good questions. > Aren’t the first 3 or 4 chapters basically what you can find in Google’s own cloud toturials? > Why does the domain-driven-design chapter come after you’ve tied the reader into GCP? I can’t think of a single enterprise business domain where that would make sense from a European GDPR driven perspective. Our idea was to create a seemingly modern app based on microservices, with full GCP setup and fancy tools used. We then go on to point the issues in the code. We wanted to show how an app that seems well built on surface can have hidden problems that are hard to spot. We don't deep dive into GCP, mostly just describe the setup. > Why do you think you can cover that many topics in a single book? I mean, part of the reason Clean Code is well liked is because it covers one topic in depth, rather than covering a bunch of different topics without ever giving the reader anything of value on any of them. I believe you'll find a lot of value on these topics, even if we don't go super-deep into each of them. It should give readers enough ideas on how to approach building complex apps. We base this on our experience, so it's not just bland descriptions of the patterns. Also it's all focused on Go and on a real example project, so it's not abstract.
gigatexal 5y ago
I’d rather pay for the book than give you my email.
- m110 5y ago
  You can still read the articles on our blog, if you're interested. The book is based on them.
- mbilal 5y ago
  You know gmail has a spam button, really easy to use btw.
deleted 5y ago
[deleted]
kardianos 5y ago
I would not recommend many of these patterns. A business application needs are specialized; create a framework for your needs, then define the application into being. Make your functions as large as makes sense, which is typically fairly large. Ignore most of these hot buzzwords. Define the needs of the application, develop a framework to meet those needs, then define the application into being. Never write a business application screen by screen; define it into being screen by screen.
- pzduniak 5y ago
  If this post were called "We wrote a book about our approach to building DDD/CQRS business software using Go", I would be perfectly fine with it. Feels like a clickbait, especially after your learn that the consultancy that wrote the book built their whole identity around being "DDD in Go" experts. Just don't push it on everyone. This kind of marketing is doing real harm to Go newbies, like that "standard Go project template" repo.
  - m110 5y ago
    Hey, thanks for the comment. I hope this doesn't seem like we say it's the only valid way to build applications. We mention throughout the book where some patterns make sense, and where they're not needed. We also write about more patterns than just DDD and CQRS, so we don't include these in the book's title.
    - pzduniak 5y ago
      Book's title is fine with me, post's title isn't. Felt like clickbait once I realized its promoting patterns that aren't useful in most of "business applications built in Go". If you already decided to use CQRS/DDD for whatever reason - yeah, its a decent resource.
      - m110 5y ago
        > I realized its promoting patterns that aren't useful in most of "business applications built in Go" I don't really agree with this. I would say most of the patterns are quite useful in majority of business applications. Unless you're dealing with trivial domains, but I believe it's not that common. Describing the book's content as DDD/CQRS is too specific, as we touch on many different patterns.
flexterra 5y ago
DDD-Lite
ToJans 5y ago
I've been involved in the European DDD community from the start, sparked the initial IDDD tour with Vaughn Vernon, and am still highly involved, so you could say I know a thing or two about DDD, and I consider the patterns most people think about when being introduced to DDD a bit similar to the inheritance part of Object orientation: it's pars pro toto and you are probably missing out on the valuable part of DDD: First: DDD will not magically fix all your problems; however, it does ask the right questions: what is your common language, how does your code align with your organisation, what are the boundaries and the relationship between boundaries, what is your core domain and where might it make more sense to buy something existing etc... So while it is not the silver bullet, it might help you to pinpoint some typical issues with your current code base. Second, people new to DDD tend to focus on tactical patterns and things like CQRS etc, which might be interesting but it's usually way less important than the strategic part of DDD. Third, it also attempts to define nomenclature for developers, f.e. about responsibilities and granularities: aggregate roots, bounded contexts, commands, events etc... Like every other methodology there is some cargo culting going on, and that is also the reason I decided to spend a few years outside the echo chamber. However, now that I'm back it's great to see how the methodology is maturing and the community trends to attract the right kind of people. TL;DR: DDD can be useful, but don't blindly start applying tactical DDD patterns everywhere without understanding the bigger picture; this will only work against you. Edit: some line breaks
Antoninus 5y ago
Big Threedots guy.
- roblaszczak 5y ago
  Pleasure is all mine!
gengstrand 5y ago
Go did rise to prominence by being the programming language behind such high profile software as Kubernetes, Docker, and Prometheus. None of those are business applications and Rob Pike (ex Bell Labs guru and co-inventor of Go) gave a presentation about Go in 2015 where he explicitly identified that Go was invented for infrastructure and not business applications. I have encountered many engineers who are excited about Go and want to adopt it for enterprise systems. In 2019. I evaluated Go for that purpose. You can read my evaluation at http://glennengstrand.info/software/architecture/microservice/golang http://glennengstrand.info/software/architecture/microservic... What I discovered is that Go is not any faster than Java on a light weight framework. Here is the part that may seem controversial for the folks here. The simplicity of Go did not result in simpler systems. I found that the lack of inheritance hampered me in expressing solutions to complex business rules and data models. Many of you may disagree with that and counter argue that inheritance is a bad thing. That is most probably one reason why there is so much interest in Go. It intentionally lacks support for inheritance. I agree that inheritance can and has been misused a lot. It is an advanced programming language feature that should be used sparingly. Removing inheritance entirely reduces the expressiveness of the programming language, especially when it comes to enterprise computing.
- dimitrios1 5y ago
  (a pedantic correction: Pike originally describes it as a systems language, which can include infrastructure) Thing is none of the above is going to apply when generics land. You mentioned kubernetes which use complex, maintainable abstractions and structures with only the facilities Go provides. There isn't that much difference between writing a maintainable system, whether the primary user is the business, or other software.
  - gengstrand 5y ago
    https://www.youtube.com/watch?v=rFejpH_tAHM https://www.youtube.com/watch?v=rFejpH_tAHM “Go is software for the parts that we work on which is mostly infrastructure.” Generics is a good thing and I look forward to seeing the details in how Go will support it.
helij 5y ago
Look, I know email marketing is everything. I would love to take a look at the book but not giving out my email, sorry.
- cbushko 5y ago
  The book content is basically on their website: https://threedots.tech/series/modern-business-software-in-go https://threedots.tech/series/modern-business-software-in-go...
ozfive 5y ago
Subscription confirmation email link goes to a 404 page on mailchimp. You guys might want to check it out.
dang 5y ago
I took "Show HN" out of this title because requiring an email signup to get access to the content is against the spirit of the rules: https://news.ycombinator.com/showhn.html https://news.ycombinator.com/showhn.html, which say that there needs to be a way for people to try it out. In the case of a book, the established way to let people "try it out" is to share a sample chapter. If you share a sample chapter on your web page, rather than just a sample page, we can put "Show HN" back. (Edit: done now.)
- cbushko 5y ago
  A heads up, the book is essential the content of their website: https://threedots.tech/series/modern-business-software-in-go/ https://threedots.tech/series/modern-business-software-in-go...
gccs 5y ago
Can someone just post a PDF of the book so I don't have to give them an email?
- m110 5y ago
  If you don't want to share your email, you can still read (almost) the same content on our blog. If you sign up, you'll have access to the most recent PDF, as we update the book with each new article.
iCarrot 5y ago
I signed up for the newsletter (~10h ago), no ebook yet but I'm apparently enrolled in a mini-course of the same name?
- m110 5y ago
  Hey, you should receive links to the ebook in the first email after confirming subscription.

269 points by roblaszczak 5y ago

It's funny to see "the real devs" rediscover the reasons why "fizzbuzz corporate" looks like it does.

Love this! Hey, one little tip. I see you're using LaTeX for the book. If you switch to xelatex to compile it, you can use your own fonts, like this: % Set the typeface to use \usepackage{fontspec} \setmainfont{Libre Baskerville} And the compile command: xelatex mybook.tex

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

rapnie 5y ago

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-example https://github.com/ThreeDotsLabs/wild-workouts-go-ddd-exampl...

m110 5y ago
Hey, one of the authors here. The example is exactly what we base the book on. The chapters go through refactoring of this app.

domano 5y ago

I signed up for the newsletter but got no link to the book so far.

roblaszczak 5y ago
Hey, unfortunately our e-mail automation is a bit slow. It should arrive to your mailbox within couple minutes :) I'll add information to subscribe confirmation page about the delay.
- domano 5y ago
  Yes it arrived, was too impatient :) Thank you
- deleted 5y ago
  [deleted]

hardwaresofton 5y ago

So I think DDD is basically one of the best pattern that has ever been discovered for developing good software (thinking of it along with gangof4, SOLID, etc). There's a lot of cruft around it and consultants looking to over-complicate it for the sake of getting hired, but viewed simply it's mostly about abstraction at conceptual boundaries -- very hard to be against that on most large projects. That said, can someone weigh in on how it is building large "enterprise-grade" applications in Go 1.x given how (purposefully) constrained the type system in Go is? 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?

llimllib 5y ago
I built a large enterprise website in go, and I can say that I barely ever even had to consider the lack of generics. Occasional slightly annoying interface shenanigans and mild interface hackery, but nothing significant at all.
- hardwaresofton 5y ago
  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/ https://gokit.io/
  - llimllib 5y ago
    I’m not the authors and don’t even really know what ddd means, sorry

moksly 5y ago

Aren’t the first 3 or 4 chapters basically what you can find in Google’s own cloud toturials? Why does the domain-driven-design chapter come after you’ve tied the reader into GCP? I can’t think of a single enterprise business domain where that would make sense from a European GDPR driven perspective. Why do you think you can cover that many topics in a single book? I mean, part of the reason Clean Code is well liked is because it covers one topic in depth, rather than covering a bunch of different topics without ever giving the reader anything of value on any of them. Have you considered going the TDD GOAT book route of earning sales? I’m really sorry that I’m so negative, but your “contents” read like every terrible tech-book I’ve ever opened. Good luck though.

m110 5y ago
Hey, these are good questions. > Aren’t the first 3 or 4 chapters basically what you can find in Google’s own cloud toturials? > Why does the domain-driven-design chapter come after you’ve tied the reader into GCP? I can’t think of a single enterprise business domain where that would make sense from a European GDPR driven perspective. Our idea was to create a seemingly modern app based on microservices, with full GCP setup and fancy tools used. We then go on to point the issues in the code. We wanted to show how an app that seems well built on surface can have hidden problems that are hard to spot. We don't deep dive into GCP, mostly just describe the setup. > Why do you think you can cover that many topics in a single book? I mean, part of the reason Clean Code is well liked is because it covers one topic in depth, rather than covering a bunch of different topics without ever giving the reader anything of value on any of them. I believe you'll find a lot of value on these topics, even if we don't go super-deep into each of them. It should give readers enough ideas on how to approach building complex apps. We base this on our experience, so it's not just bland descriptions of the patterns. Also it's all focused on Go and on a real example project, so it's not abstract.

gigatexal 5y ago

I’d rather pay for the book than give you my email.

m110 5y ago
You can still read the articles on our blog, if you're interested. The book is based on them.
mbilal 5y ago
You know gmail has a spam button, really easy to use btw.

deleted 5y ago

[deleted]

kardianos 5y ago

I would not recommend many of these patterns. A business application needs are specialized; create a framework for your needs, then define the application into being. Make your functions as large as makes sense, which is typically fairly large. Ignore most of these hot buzzwords. Define the needs of the application, develop a framework to meet those needs, then define the application into being. Never write a business application screen by screen; define it into being screen by screen.

pzduniak 5y ago
If this post were called "We wrote a book about our approach to building DDD/CQRS business software using Go", I would be perfectly fine with it. Feels like a clickbait, especially after your learn that the consultancy that wrote the book built their whole identity around being "DDD in Go" experts. Just don't push it on everyone. This kind of marketing is doing real harm to Go newbies, like that "standard Go project template" repo.
- m110 5y ago
  Hey, thanks for the comment. I hope this doesn't seem like we say it's the only valid way to build applications. We mention throughout the book where some patterns make sense, and where they're not needed. We also write about more patterns than just DDD and CQRS, so we don't include these in the book's title.
  - pzduniak 5y ago
    Book's title is fine with me, post's title isn't. Felt like clickbait once I realized its promoting patterns that aren't useful in most of "business applications built in Go". If you already decided to use CQRS/DDD for whatever reason - yeah, its a decent resource.
    - m110 5y ago
      > I realized its promoting patterns that aren't useful in most of "business applications built in Go" I don't really agree with this. I would say most of the patterns are quite useful in majority of business applications. Unless you're dealing with trivial domains, but I believe it's not that common. Describing the book's content as DDD/CQRS is too specific, as we touch on many different patterns.

flexterra 5y ago

DDD-Lite

ToJans 5y ago

I've been involved in the European DDD community from the start, sparked the initial IDDD tour with Vaughn Vernon, and am still highly involved, so you could say I know a thing or two about DDD, and I consider the patterns most people think about when being introduced to DDD a bit similar to the inheritance part of Object orientation: it's pars pro toto and you are probably missing out on the valuable part of DDD: First: DDD will not magically fix all your problems; however, it does ask the right questions: what is your common language, how does your code align with your organisation, what are the boundaries and the relationship between boundaries, what is your core domain and where might it make more sense to buy something existing etc... So while it is not the silver bullet, it might help you to pinpoint some typical issues with your current code base. Second, people new to DDD tend to focus on tactical patterns and things like CQRS etc, which might be interesting but it's usually way less important than the strategic part of DDD. Third, it also attempts to define nomenclature for developers, f.e. about responsibilities and granularities: aggregate roots, bounded contexts, commands, events etc... Like every other methodology there is some cargo culting going on, and that is also the reason I decided to spend a few years outside the echo chamber. However, now that I'm back it's great to see how the methodology is maturing and the community trends to attract the right kind of people. TL;DR: DDD can be useful, but don't blindly start applying tactical DDD patterns everywhere without understanding the bigger picture; this will only work against you. Edit: some line breaks

Antoninus 5y ago

Big Threedots guy.

roblaszczak 5y ago
Pleasure is all mine!

gengstrand 5y ago

Go did rise to prominence by being the programming language behind such high profile software as Kubernetes, Docker, and Prometheus. None of those are business applications and Rob Pike (ex Bell Labs guru and co-inventor of Go) gave a presentation about Go in 2015 where he explicitly identified that Go was invented for infrastructure and not business applications. I have encountered many engineers who are excited about Go and want to adopt it for enterprise systems. In 2019. I evaluated Go for that purpose. You can read my evaluation at http://glennengstrand.info/software/architecture/microservice/golang http://glennengstrand.info/software/architecture/microservic... What I discovered is that Go is not any faster than Java on a light weight framework. Here is the part that may seem controversial for the folks here. The simplicity of Go did not result in simpler systems. I found that the lack of inheritance hampered me in expressing solutions to complex business rules and data models. Many of you may disagree with that and counter argue that inheritance is a bad thing. That is most probably one reason why there is so much interest in Go. It intentionally lacks support for inheritance. I agree that inheritance can and has been misused a lot. It is an advanced programming language feature that should be used sparingly. Removing inheritance entirely reduces the expressiveness of the programming language, especially when it comes to enterprise computing.

dimitrios1 5y ago
(a pedantic correction: Pike originally describes it as a systems language, which can include infrastructure) Thing is none of the above is going to apply when generics land. You mentioned kubernetes which use complex, maintainable abstractions and structures with only the facilities Go provides. There isn't that much difference between writing a maintainable system, whether the primary user is the business, or other software.
- gengstrand 5y ago
  https://www.youtube.com/watch?v=rFejpH_tAHM https://www.youtube.com/watch?v=rFejpH_tAHM “Go is software for the parts that we work on which is mostly infrastructure.” Generics is a good thing and I look forward to seeing the details in how Go will support it.

helij 5y ago

Look, I know email marketing is everything. I would love to take a look at the book but not giving out my email, sorry.

cbushko 5y ago
The book content is basically on their website: https://threedots.tech/series/modern-business-software-in-go https://threedots.tech/series/modern-business-software-in-go...

ozfive 5y ago

Subscription confirmation email link goes to a 404 page on mailchimp. You guys might want to check it out.

dang 5y ago

I took "Show HN" out of this title because requiring an email signup to get access to the content is against the spirit of the rules: https://news.ycombinator.com/showhn.html https://news.ycombinator.com/showhn.html, which say that there needs to be a way for people to try it out. In the case of a book, the established way to let people "try it out" is to share a sample chapter. If you share a sample chapter on your web page, rather than just a sample page, we can put "Show HN" back. (Edit: done now.)

cbushko 5y ago
A heads up, the book is essential the content of their website: https://threedots.tech/series/modern-business-software-in-go/ https://threedots.tech/series/modern-business-software-in-go...

gccs 5y ago

Can someone just post a PDF of the book so I don't have to give them an email?

m110 5y ago
If you don't want to share your email, you can still read (almost) the same content on our blog. If you sign up, you'll have access to the most recent PDF, as we update the book with each new article.

iCarrot 5y ago

I signed up for the newsletter (~10h ago), no ebook yet but I'm apparently enrolled in a mini-course of the same name?

m110 5y ago
Hey, you should receive links to the ebook in the first email after confirming subscription.