DEV Community

Cover image for Using Domain-Driven Design(DDD)in Golang
Steven Victor
Steven Victor

Posted on • Updated on

Using Domain-Driven Design(DDD)in Golang

Domain-Driven Design pattern is the talk of the town today.
Domain-Driven Design(DDD) is an approach to software development that simplifies the complexity developers face by connecting the implementation to an evolving model.

Note

This is not an article that explains the "ideal" way to implement DDD in Golang because the author is no way an expert on it. This article is rather the author's understanding of DDD based on his research. The author
will be very grateful to contributions on how to improve this article.

Check the github repo for the updated code:
https://github.com/victorsteven/food-app-server

Why DDD?
The following are the reasons to consider using DDD:

  • Provide principles & patterns to solve difficult problems
  • Base complex designs on a model of the domain
  • Initiate a creative collaboration between technical and domain experts to iteratively refine a conceptual model that addresses domain problems.

The idea of Domain-Driven Design was inverted by Eric Evans. He wrote about it in a book which you can find some of the highlights here

DDD comprises of 4 Layers:

  1. Domain: This is where the domain and business logic of the application is defined.
  2. Infrastructure: This layer consists of everything that exists independently of our application: external libraries, database engines, and so on.
  3. Application: This layer serves as a passage between the domain and the interface layer. The sends the requests from the interface layer to the domain layer, which processes it and returns a response.
  4. Interface: This layer holds everything that interacts with other systems, such as web services, RMI interfaces or web applications, and batch processing frontends.

Alt Text
To have a thorough definition of terms of each layer, please refer to this

Let's get started.

We are going to build a food recommendation API.

You can get the code if you don't have all the time to read.
Get the API code here.
Get the Frontend code here.

The very first thing to do is to initialize the dependency management. We will be using go.mod. From the root directory(path: food-app/), initialize go.mod:

go mod init food-app

This is how the project is going to be organized:

Alt Text

In this application, we will use postgres and redis databases to persist data. We will define a .env file that has connection information.
The .env file looks like this:


This file should be located in the root directory(path: food-app/)

Domain Layer

We will consider the domain first.
The domain has several patterns. Some of which are:
Entity, Value, Repository, Service, and so on.

Alt Text

Since the application we are building here is a simple one, we consider just two domain patterns: entity and repository.

Entity

This is where we define the "Schema" of things.
For example, we can define a user's struct. See the entity as the blueprint to the domain.

From the above file, the user's struct is defined that contains the user information, we also added helper functions that will validate and sanitize inputs. A Hash method is called that helps hash password. That is defined in the infrastructure layer.
Gorm is used as the ORM of choice.

The same approach is taken when defining the food entity. You can look up the repo.

Repository

The repository defines a collection of methods that the infrastructure implements. This gives a vivid picture of the number of methods that interact with a given database or a third-party API.

The user's repository will look like this:

The methods are defined in an interface. These methods will later be implemented in the infrastructure layer.

Almost the same applies to the food repository here.

Infrastructure Layer

This layer implements the methods defined in the repository. The methods interact with the database or a third-party API. This article will only consider database interaction.

Alt Text

We can see how the user's repository implementation looks like:

Well, you can see that we implemented the methods that were defined in the repository. This was made possible using the UserRepo struct which implements the UserRepository interface, as seen in this line:

//UserRepo implements the repository.UserRepository interface
var _ repository.UserRepository = &UserRepo{}

You can check the repository on how the food repository was implemented here.

So, let's configure our database by creating the db.go file with the content:



From the above file, we defined the Repositories struct which holds all the repositories in the application. We have the user and the food repositories. The Repositories also have a db instance, which is passed to the "constructors" of user and food(that is, NewUserRepository and NewFoodRepository).

Application Layer

We have successfully defined the API business logic in our domain. The application connects the domain and the interfaces layers.

We will only consider the user's application. You can check out that of the food in the repo.

This is the user's application:

The above have methods to save and retrieve user data. The UserApp struct has the UserRepository interface, which made it possible to call the user repository methods.

Interfaces Layer

The interfaces is the layer that handles HTTP requests and responses. This is where we get incoming requests for authentication, user-related stuff, and food-related stuff.

Alt Text

User Handler

We define methods for saving a user, getting all users and getting a particular user. These are found in the user_handler.go file.

I want you to observe that when returning the user, we only return a public user(which is defined in the entity). The public user does not have sensitive user details such as email and password.

Authentication Handler

The login_handler takes care of login, logout and refresh token methods. Some methods defined in their respective files are called in this file. Do well to check them out in the repository following their file path.

Food Handler

In the food_handler.go file, we have methods for basic food crud: creating, reading, updating, and deleting food. The file has explanations of how the code works.

Please note, when testing creating or updating food methods via the API using postman, use form-data not JSON. This is because the request type is multipart/form-data.

Running the Application

So, let's test what we've got. We will wire up the routes, connect to the database and start the application.

These will be done in the main.go file defined in the directory root.

The router(r) is of type Engine from the gin package we are using.

Middleware

As seen from the above file, Some routes have restrictions. The AuthMiddleware restricts access to an unauthenticated user. The CORSMiddleware enables data transfer from different domains. This is useful because VueJS is used for the frontend of this application and it points to a different domain.
The MaxSizeAllowed middleware stops any file with size above the one the middleware specifies. Since the food implementation requires file upload, the middleware stops files greater than the specified to be read into memory. This helps to prevent hackers from uploading an unreasonable huge file and slowing down the application. The middleware package is defined in the interfaces layer.

We can now run the application using:

go run main.go

Bonus

  • Vue and VueX are used to consume the API. Get the repository here, You can also visit the url and play with it.
  • Test cases are written for most of the functionality. If you have time, you can add to it. To achieve unit testing for each of the methods in our handler, we created a mock package(in the utils directory) that mocks all the dependencies that are used in the handler methods.
  • Circle CI is used for Continuous Integration.
  • Heroku is used to deploy the API
  • Netlify is used to deploy the Frontend.

Conclusion

I hope you didn't have a hard time following this guideline on how to use DDD in when building a golang application. If you have questions or any observations, please don't hesitate to use the comment section. As said early, the author is not an expert on this. He simply wrote this article based on his use case.
Get the API code here.
Get the Frontend code here.
You can also visit the application url and play with it.

Check out other articles on medium here.

You can as well follow on twitter

Happy DDDing.

Discussion (26)

Collapse
ejemba profile image
Epo Jemba

Hi Steven, thank you for the article, there is not much DDD articles so this is good thing.

However, I have some observations regarding implementation details.

1) You start by "DDD comprises of 4 Layers" Domain, Infrastructure, Application, Interfaces then ... You put Infrastructure inside Domain ! Infrastructure package should be on the same level as Domain, Application and Interfaces. That is because Infrastructure layer brings support to all 3 others layers, not only domain. You can define go service interface inside your application package then have its implementation inside infrastructure because the implementation brings some weird dependencies.

2) packages "utils" :S in DDD you should not have an "utils" package. Everything have a place.
Auth and Security are infrastructure stuff

Middleware and FileUpload are Interfaces stuff

3) You talk about Entities but not about Agregates, you separate Repositories from Entities, their should be colocated in the same package , the "agregate" which name should be the aggregate name. Modularity is a big principle of DDD. Interchangeable component losely coupled with big cohesion.

4) In food_app.go in the application layer, there is a Service Interface , good. But there is no Factory for it, the struct implementation is just public to everyone "type FoodApp struct{...}" , it should be private and be called something like "type foodService struct {}" Factories are important because they help construct the object (inject services if needed, instrument it, etc )

5) The factory of your repository should
a) be inside the infrastructure package
func NewUserRepository(db *gorm.DB) repository.UserRepository
b) it takes an infrastructure object gorm.DB that the caller should not handle

6) You could use the DomainRegistry pattern to handle the restitution of the different factories (service, repo, aggregates). DomainRegistry interface in domain root then the DomainRegistry implementation in the infrastructure

In fact, there are other concerns but I think you get the point. Tactical patterns of DDD are direction to follow this is not strict if we respect certain rules.

Don't get me wrong this is just a fair critics. Because every one is learning, me the first. But from what I see the article can confuse first time DDD players because you break some principles.

If you want I can fork you repository and propose something we can discuss on.

Collapse
stevensunflash profile image
Steven Victor Author

Great. Thanks, a lot Epo for the feedback.

For the first point, The Infrastructure Layer is actually on the same level as the Domain. This was not the case in the first push. It had long been corrected. Please check.

For the second point, I'm currently refactoring to have the Auth in the infrastructure(have been a bit busy at work), I will probably update before the week runs out.

For the third point, I will refactor to that. Thanks.

For the fourth point, that was an oversight. The change has been effected now.

For the fifth point, I didn't quite get you. But this no longer applies in the implementation above.
func NewUserRepository(db *gorm.DB) repository.UserRepository
The article is currently in a constant state of editing as constructive feedback such as yours are given. If you don't mind, can you elaborate on your fifth point?

Please go ahead and fork the repository, your changes are welcome.

Thanks again for the feedback.

Collapse
kolkov profile image
Comment marked as low quality/non-constructive by the community. View Code of Conduct
Andrey Kolkov

damianopetrungaro.com/posts/ddd-us...
I think it's the best articles about DDD and Go.

Collapse
cardozo17 profile image
José Antonio Cardozo • Edited on

Hello Victor. First of all I wanted to thank you because your project have been very helpful as an example for implementing a project of my own. I have a question for you about the code tho. Why in the api in the refresh token method you just erase the refresh token and not the previous generated access token in the redis db. It seems like it will always remain an orphan access token in the redis database if you do this I think. Is there any reason for you to do that?. Thanks again.

Collapse
stevensunflash profile image
Steven Victor Author

Hi Jose,

For we to ever use the Refresh Token, it means the Access Token must have expired(and Redis deletes it automatically).

Collapse
cardozo17 profile image
José Antonio Cardozo

Hi Steven. Thanks for the answer. That makes sense. I will check it out it might be something on my implementation. The other thing is I don't see in the code in the frontend where you are encripting the password with the Bcrypt. Is that missing? or am I just don't seeing it?.

Thank you.

Thread Thread
stevensunflash profile image
Steven Victor Author

Hi,
The password is encrypted on the backend.
Go to this path: infrastructure/security/password.go
The function that hashes the password is defined there.

Collapse
nicolasassi profile image
Nicolas Augusto Sassi

Hey there! I got little confused with the Application layer in your example... It just feels a bit pointless as it only reproduces the Repository and doesn't actually do anything different than that. Could you please explain or give some example of how the application layer could grow in a way that it gets more "usefull"?

Thanks!

Collapse
tranluongtuananh profile image
TranLuongTuanAnh

Hi Steven, thank you for the article, I have a question!

Why do you pass a repository as param when init interface?
Such as services.Food is passed as params of interfaces.NewFood initialization.
foods := interfaces.NewFood(services.Food, services.User, fd, redisService.Auth, tk)

I think that pass a application is better choice! How do you think about it?

Collapse
stevensunflash profile image
Steven Victor Author

Hi bro, Sorry for the late reply. Just seeing this now. interfaces.NewFood() is a constructor, so we inject dependencies of other services. This is considered best practice, so you avoid the usage of globals in your code.

Collapse
hades32 profile image
Martin Rauscher

Why did you choose to return interfaces e.g. in your repository creation functions? Isn't that against recommended Go best practices?

Collapse
stevensunflash profile image
Steven Victor Author

Hi Martin. Thanks for the feedback.
In order to answer your question properly, can you include a code snippet to a comment where you observed this?

Thanks.

Collapse
alikhil profile image
Alik Khilazhev

For those who are looking for articles about DDD in Go, I would recommend reading this

Collapse
kolkov profile image
Comment marked as low quality/non-constructive by the community. View Code of Conduct
Andrey Kolkov

damianopetrungaro.com/posts/ddd-us... very good article about DDD with Golang.

Collapse
martinsaporiti profile image
martinsaporiti

Great article. I have a question. Is it correct that the entity "User" knows about gorm? Should the entities know about de persistence strategy? thanks in advance.

Collapse
rpoletaev profile image
Roman Poletaev

I can't understand why people choose golang on this way

Collapse
kolkov profile image
Comment marked as low quality/non-constructive by the community. View Code of Conduct
Andrey Kolkov

What's problem with Golang and DDD?
damianopetrungaro.com/posts/ddd-us...

Collapse
sda0 profile image
Comment marked as low quality/non-constructive by the community. View Code of Conduct
Info Comment hidden by post author - thread only accessible via permalink
Denis S

Bad guide, I'm not sure author understands DDD

Collapse
stevensunflash profile image
Steven Victor Author • Edited on

Hi Dennis, thanks for the feedback. Please can you point areas you were not okay with(the bad stuff), as regards this implementation? Supporting links will also be helpful.

Though the author is not yet a DDD expert, he did some research before writing this.

These are some of the author's references:

engineering.grab.com/domain-driven...

newtonmeters.com/blog/domain-drive...

github.com/marcusolsson/goddd

github.com/takashabe/go-ddd-sample

If these references are also a bad guide, the author will appreciate it if he is pointed to a good guide, how DDD is implemented.

Thanks as I anticipate your response.

Collapse
kskitek profile image
kskitek

This article makes a huge disservice to DDD.

The article focuses on project structure and layers like it is some stiff guideline for DDD whereas it is not.

DDD is about describing the domain in the code. Then building upon this domain code to create some useful use cases (also dropping in some infrastructural code for persistence, messaging and stuff like that). DDD is about direction of dependencies and direction of control in those mentioned "layers". About loosely coupled layers. It is about how your application can grow around the domain.
In application that follows DDD principles, I should be able to tell what is the application about just looking at the packages.. In application from the article I just know that this is another weekend application.

Thread Thread
stevensunflash profile image
Steven Victor Author

Great! Thanks Kskitek for the feedback. I'm no way close to perfection. I wrote about this based on how I implemented DDD for a small application I built(which the link is shared in the article).

To help me better understand, do you have any material, link, video, article, github repo, anything at all, that explained how DDD is implemented the "ideal" way in Golang? I and the rest of the people reading this article will greatly benefit.

Thanks as I anticipate your response.

Thread Thread
delphinocons profile image
Angelo Hulshout 🇮🇹 🇳🇱

Hey Steven,

I have to agree ksiktek here. I have a feeling you were a bit too quick with diving into the implementation. Although in the end the implementation is what it all comes down to, that is not the essence of DDD. Instead DDD is - as you mentioned, but not deepened further - about creating a design in such a way that it is

  • understandable for you as a software engineer (and your collegues)
  • understandable for your customers (that's something most other approaches don't)
  • brings the problem domain (your customer's world) and the solution domain (your world of code) together in one solution

In doing so, it removes some of the steps that 'traditional' software development took: first create a functional or conceptual design, then translate that into technical design and finally translate that into code. In each translation, information got filtered or lost, resulting in all the bugs and mismatches that we see nowadays between software as it was built and software as it was intended.

I've been teaching DDD courses for over 7 years now, and I will be posting short digestable articles about it over the coming months (transferring my training material to either Medium or Dev.to for those who can't attend - or want to revisit the material after the training). Feel free to dive in. If you drop me a message here or on twitter (@delphinocons ) I'll send you an invite for the newsletter that I'm launching related to these same articles. And of course, feel free to ask if you have specific questions. :-)

Thread Thread
stevensunflash profile image
Steven Victor Author

Hi Angelo,

Thanks for your comment. I will really be looking forward to your posts as it will help me better understand DDD better.

I kindly request that you also share the link here when it is ready.

Thanks.

Thread Thread
delphinocons profile image
Angelo Hulshout 🇮🇹 🇳🇱

Hello Steven, you're welcome. The articles will be posted on Medium and here on Dev.to, so I'm sure you'll catch them. I also have a newsletter, which is released in lock step with the articles. If you subscribe to that you will get automatic notifications of new articles: eepurl.com/g1oOaD

Thread Thread
stevensunflash profile image
Steven Victor Author

great

Thread Thread
delphinocons profile image
Angelo Hulshout 🇮🇹 🇳🇱

Some comments have been hidden by the post's author - find out more