Domain-Driven Design in Go: Writing Code Around the Problem

At GopherCon Africa 2026, one of the concepts that caught my attention during the Go workshop was Domain-Driven Design (DDD).

The idea is simple: your code should reflect the problem you're trying to solve, not just the technology you're using.

But what does that actually mean when you're writing Go?

Let's use a simple example.

*What is Domain-Driven Design?
*
DDD is an approach to software development that focuses on understanding the business problem before deciding how to build the solution.

Imagine we're building a smart irrigation system to help farmers determine when their crops need water.

Our application might involve sensors, a database, and an API. But those are just the technical components.

The actual problem we're solving revolves around farms, soil conditions, and irrigation decisions.

DDD encourages us to model these concepts in our code.

What does this look like in Go?

Go gives us structs and methods that we can use to represent concepts from our problem domain.

For example, imagine we're working with soil moisture readings:

package main

import "fmt"

type SoilMoisture struct {
Percentage float64
}

func (s SoilMoisture) NeedsWater() bool {
return s.Percentage < 30
}

func main() {
soil := SoilMoisture{Percentage: 25}

if soil.NeedsWater() {
    fmt.Println("The soil may need watering.")
}

}

Here, SoilMoisture represents a concept in our application, while NeedsWater() expresses a simple rule related to it.

The 30% threshold is illustrative. A real irrigation system would need to consider factors such as soil type, crop requirements, and sensor readings before making a recommendation.

The interesting part is that the rule is connected to the concept it describes. We're not hiding it inside a database query or an HTTP handler.

It's a small example, but it demonstrates how we can make our code reflect the problem we're solving.

Why does this matter?

As applications grow, mixing business rules with database operations and HTTP handlers can make changes harder to manage.

Separating these responsibilities can help us:

Maintain our code: Changes to one component are less likely to affect unrelated parts.

Test business rules: We can test important behaviour without always needing a database or external service.

Understand the application: Code becomes easier to navigate when its structure reflects the problem we're solving.

Of course, DDD involves more than structs and methods. Understanding the business domain and using its language consistently are also important.

And not every project needs a complicated architecture. Sometimes, a simple structure is all you need.

What did I get from all this?

One thing I'm learning is that writing software isn't just about making features work. It's also about how we organise our code so we can understand and maintain it as the application grows.

DDD encourages us to start with the problem, identify the concepts that matter, and let that understanding guide our design.

I'm still exploring these concepts, but it's interesting to see how a little thought about structure can make a difference in how we build software.

Good code isn't necessarily code with more layers. Sometimes, it's code that represents the problem clearly.

Attending GopherCon Africa opened my mind to a whole new set of possibilities. I'm realising just how much there is to learn beyond simply getting code to work.

How do you approach structuring your Go projects?