Domain Driven Design in Go
Domain Driven Design, or DDD, is a software development practice that aims to bridge the gap between developers and the business experts. During my time at Citerus, I consulted teams on Domain Driven Design practices.
A key component of Domain Driven Design is the idea of a ubiquitous language—a shared language used in conversations between the business and the developers. Since this shared language is reflected in the code that developers write, it becomes easier to communicate design choices and even bugs.
Building a sample application in Go
Citerus had built a sample application written in Java in collaboration with Eric Evans, intended to demonstrate code written by a team that practices DDD.
At the time though, the teams I was part of were using Go rather than Java. It wasn’t obvious how the ideas from DDD would translate into a programming language like Go.
I started exploring how to port the Java sample application into idiomatic Go. I published goddd along with an AngularJS frontend and routing service.
Sharing my findings
I shared some of my initial Thoughts on DDD in Go, and in 2014, I gave a demo at the local Go meetup.
In 2015, I wrote a three-part blog series where I walked through the design and the architecture of the sample application.
- Domain Driven Design in Go: Part 1
- Domain Driven Design in Go: Part 2
- Domain Driven Design in Go: Part 3
In 2016, my talk Building an enterprise service in Go got accepted to Golang UK, London 2016.
After having talked with some of the other attendees, I wrote some clarifying Notes on my GolangUK 2016 talk.
Articles like Go and a Package Focused Design and A Collection of Structuring Go used my work to compare different ways of structuring Go applications.
Later, I contributed part of the code as the shipping example for the Go kit microservice toolkit.
My work inspired discussions on Domain Driven Design in the Go community, leading to articles and projects from community members further improving on the initial ideas.