Go with the Domain

Description

It’s 2017, and we join a startup. We work full-time in Go now, which starts getting popular. It’s an exciting time, as we’re about to kick off an ambitious greenfield project. We’re determined to do the impossible: add features quickly and keep the application maintainable. At this point, we’ve already seen complex software that’s hell to maintain. It’s often the key to the company’s success, but no one wants to touch it. The last thing we want is for our application to end up like this. Some may think it’s the natural order of things, but we naively can’t accept that. So we spend evenings studying books on Domain-Driven Design, reading blogs on Clean Architecture, and watching talks on CQRS and Event-Driven Programming. These patterns are supposedly used only in enterprise applications, so there is almost nothing on the web on using them in Go. We’re in the dark most of the time but also fueled with enthusiasm. We push through and apply the ideas, trying things out on the way. We find out the patterns work, and they play well with Go. Go’s explicit and straightforward way of doing things is a perfect fit for the domain-focused approach. Our team feels productive, collaboration goes smoothly, and it’s fun to work with the project. We also see again and again that implementation details are often just… details. We realize how important it is to get the domain code right. Not only in the “clean code” sense but also in a “correctly modeled” way. We give up some coding time to talk with people and better understand what we’re going to build. It always pays back. We’d love to tell you everything turned out to be a huge success, but that’s not what happened. It’s the startup reality you don’t read about on Hacker News. However, we’ve learned a lot from our successes and (especially) mistakes. Over the last few years, we kept working on the ideas, and we still keep improving them. Go with the Domain is our attempt to share what we’ve learned with you.