m110

Makes sense, but this artifact is still a simplification, right? The domain model isn't just this one artifact in the code but the broader "idea".

Isn't code what defines the constraints though?

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.

Take a look at: https://github.com/ThreeDotsLabs/wild-workouts-go-ddd-exampl...

(I’m one of the authors.)

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.

Thanks! I had a paragraph about delta time but since Ebitengine works based on the TPS, I eventually decided to drop it to not make it confusing.

Here's a good summary, I think I'll link it in my post: https://ebitencookbook.vercel.app/blog/2022/04/16/TPS

Oops, that was a leftover! Thank you :)

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)

Senior Backend Engineer: https://boards.eu.greenhouse.io/getharley/jobs/4209229101

Senior Frontend Engineer: https://boards.eu.greenhouse.io/getharley/jobs/4209222101

Senior Data Engineer: https://boards.eu.greenhouse.io/getharley/jobs/4222751101

Glad to hear that! :D

As mentioned in the other comment, the heavy lifting is done by Ebitengine: https://ebitengine.org/en/documents/webassembly.html

Go supports compiling to wasm, and it's as simple as:

  GOOS=js GOARCH=wasm go build -o web/game.wasm

It takes just a few seconds for this project. :)

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. :)

There are only two levels at the moment, it's still a prototype. :) And missing a "well done!" screen, obviously.

Thanks! The game is not really balanced at this point, it definitely could use some play testing and improvements. :)

Thank you!

Go makes it ridiculously easy:

  GOOS=js GOARCH=wasm go build -o web/game.wasm

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.

Can you share how to reach this understanding? How would you learn it if not from a set of patterns and guidelines?

It’s like saying „write good software” without any advice how to do it.

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.

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

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 think it's probably closer to the onion architecture, as DDD doesn't concern much about infrastructure. But it's kind of mixed up. You could also call it just SRP or separation of concerns.

I think the advantage of sticking to a specific "architecture" pattern is you don't waste time discussing where to put what, you just agree to one way and do it.

Ah, I get it now. You meant in in the context of onion/clean/hexagonal architecture. :)

You can still read the articles on our blog, if you're interested. The book is based on them.

I think you mix some things up. go-kit is very far away from DDD. It even says on their website: "Focus on your business logic.". It's basically everything but not the domain code.

For CRUD-y apps, you usually wouldn't need the DDD patterns at all, as there's no complex business logic to model.

> the parts where the complexity would be worth it are often already done for you by the libraries/frameworks used.

I'm really confused about this. The most complexity comes from complex business scenarios you need to handle somehow in code. No framework is flexible enough to do it for you. Using DDD, you would keep a "pure" layer of domain code that does just that.

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

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.

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

It's not about the throughput though, but about consistency. You can't do the same thing on Redis if it's not your main storage. You need to have transactions on level of the database engine your application uses.