Where Does This Code Go? Layers in Go

Until not too long ago, when I wanted to change one thing in my code, I'd end up having to touch a bunch of other things. Or I'd be staring at a function trying to figure out why it's doing three completely different jobs. Turns out there's a name for what I was doing wrong, and a pattern that fixes it. This article is essentially what I wish someone had shown me earlier. We're going to walk through a way of organising your Go code into three layers: Service, Repository, and Delivery… So that each part of your code has one job, and changing one thing doesn't ripple into everything else. I'll be using two of my own projects as examples: a netcat-based group chat app, and a URL shortener. What is Separation of Concerns? Before we get into the layers, it's worth naming the idea behind all of this. Separation of concerns basically means: each part of your code should have one clear job, and should know as little as possible about everything else. That's it. The reason this matters is that