TL;DR I made a demo project of how to use Golang to produce the map tiles for use in LeafletJS’s tile layer. I did it mainly to catalog how I managed to solve a few of the issues I had faced in a real-world project, just in case it would be useful to someone (future me included). Some of the things I had to solve were: How to tile map images on the fly in Go How to cope with updating the image for a given area (e.

Overview I found that my Golang port of the SimpleCQRS project had a) a few errors that I really should fix, and b) should probably be refactored to be non-blocking on the command submission (up for debate I guess). While fixing them I discovered a new way to look at eventual consistency (and learned to be ok with it). First, the fix I decided one day to run Go’s race detector on the code from the original port, only to find that there was a data race!

TL;DR I ported Greg Young’s Simple CQRS Example to Go. Check it out here: Golang Version. Why Mainly because I wanted to see if I could implement something very similar in Go. In particular, I wanted to see if I could find a way to implement the functionality of the AggregateRoot abstract class (without using the method overloading that it relies on). Interesting bits The C# example uses subclassing and method overloading to make sure the correct logic is called on the aggregate root objects for both commands and events.

TL;DR The Repository pattern is commonly used in DDD / Clean Architecture / Hexagonal Architecture projects. However, porting a Java/C# reference implementation of this pattern to Golang is not as straightforward as it seems. By forcing ourselves to avoid the ‘questionable choices’ common in many examples of this pattern in Golang, we can arrive at an interesting variant of the pattern. Intro I stumbled across a dodgy hybrid technique for implementing the repository pattern in Golang that I think it quite useful and practical, especially for smaller projects.