I noticed this frustration gets worse with a long feedback loop.
I recently reworked a CI pipeline over two weeks, and it was a nightmare to make tiny changes, push it, and wait 5-10 minutes to see another error because of a YAML typo.
If possible, I try to shorten this feedback loop early.
Another option is picking something radically different to work on for a while, if possible.
This project shows how to apply more complex patterns popular in business applications while staying true to the Go ideas, and not copying them blindly from Java.
In the Go community, you’ll often hear people say „just keep things simple” beats all patterns and is all you need. This may be true if you write a CLI tool or a small library, but if you have a team maintaining a big application, some patterns are super helpful.
GetHarley | REMOTE | Europe | Senior Backend Engineer - Senior Frontend Engineer - Senior Data Engineer | Full-Time
At GetHarley (https://www.getharley.com/) we build the first platform that combines technology, clinicians, knowledge and medical-grade products. We deliver personalised skincare plans which empower our patients to look and feel their best selves.
- Secured series B this year and are now looking for product-minded engineers to help us scale further
- You'll be joining a small product engineering team (6 people) where you will have a real impact
- Looking for people who own their work end-to-end and prefer being close to the product discussions
- The tech stack is Go and React (details in the links below)
It really was! There's something about moving sprites on screen that's super satisfying compared to using a big game engine. I definitely recommend trying out Ebitengine. :)
It's not a "serious" project. I chose Go specifically because I like the language (and Ebitengine is super fun to work with) and I like the idea behind ECS. I made games with Unity before, which you could consider a "serious" engine, but the fun of development is nowhere near what I experienced here.
Thinking about what would be the most efficient engine for the game would kill all the fun for me and the project wouldn't exist. :)
This is what the article mentions. It’s not about the tactical patterns, but the strategic ones.
DDD is absolutely not about factories or dependency injection. It seems like you mix up Java with OOP design patterns and DDD and treat them all like the same thing. They’re not.
Well, this is bascially what DDD proposes. To write code that reflects the domain, so even your manager understands it. But for some reason, when you call it by a name, people start saying you don’t need those dogmatic patterns. That’s my point.
So you’re saying because software is a „craft” you can’t write down ideas how to do it better? Your bullet points are exactly this. The only thing that makes them different from „patterns” is you didn’t give them a name.
DDD is just one way to do it. You can as well call it „Focus on what you’re solving instead of implementation details”. DDD just provides patterns to follow this approach.
It’s easy to say „just write simple code”, but how do you do it? It’s not an advice someone can follow. Complex domains have many challenges where having patterns helps.
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.
> 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.
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.
I recently reworked a CI pipeline over two weeks, and it was a nightmare to make tiny changes, push it, and wait 5-10 minutes to see another error because of a YAML typo.
If possible, I try to shorten this feedback loop early.
Another option is picking something radically different to work on for a while, if possible.