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.

TL;DR Thinking about deleting objects and records can often lead to good modelling insights. However, most patterns, guides, prototypes etc focus on creating, updating and persisting items, and gloss over the issues presented by thinking about delete. I recommend putting “delete” into the early use cases and/or repository-style interfaces, as it forces you to address assumptions about the lifetime of objects and what it means for their relationships. How I came upon this Most prototyping is about getting something to demonstrate.