Chapter 10-Structuring our project

Building a Microservice with Go

The following list is the previous chapters of this series:

• Chapter 1 — Introduction to Microservices
• Chapter 2 — Introduction to Microservices (Part 2)
• Chapter-3 Domain-driven design and microservices
• Chapter -4 Advantages of using Go for web development
• Chapter — 5 Understanding HTTP Protocols and REST APIs
• Chapter-6 HTTP Package in Golang
• Chapter 7 — Step-by-step guide on building a simple web service using Go
• Chapter 8 “ Documenting our APIs — Introduction to OpenAPI”
• Chapter 9 -Building a Microservice with Go (Defining the technologies )

I recommend you take a look at the previous chapters if you have not read them yet. That will help you to get more knowledge in this wonderful world of “Microservices architecture”.

Structure

In this chapter, the following topics will be covered:

• Structuring our project
• Importance of a good code Structure
• Adding a software architecture to our microservices

Introduction

Organizing software code within a project is paramount to maintaining order, comprehension, and scalability as the project evolves. A robust structure fosters collaborative efforts among developers and streamlines the integration of novel functionalities.

It’s important to note that the specific arrangement may diverge based on programming language, framework, and team conventions. Above all, consistency and intuitiveness are paramount, serving to uphold the project’s tidiness and facilitating its manageability amidst expansion.

Throughout this book, our focal point will be on the microservices of Orders, Shopping Carts, and Users. This approach ensures a contextual abstraction, rendering concepts and associated codes readily graspable.

The uniform code structure will be shared mainly across microservices, leveraging elements of Domain-Driven Design principles alongside the standard Golang packages.

Defining packages

In this section, we delve into the packages essential for our use case. Initially, we thoroughly examine the packages recommended by Golang, offering a comprehensive description of each. These packages are pivotal in shaping the structure of our project.

Simultaneously, we examine the architectural framework of the microservice under choice for this chapter — the “Shopping Cart.” This meticulously designed structure serves as a blueprint for the other microservices that are part of our use case.

Golang standard package that will be used by our solution

In a Go project, the directories named cmd, internal, and pkg are common conventions used to structure code and modularize it, serving a specific purpose in project organization:

cmd

The cmd (stands for “commands”) directory is used to house the application’s executable entry points. Each subdirectory in cmd could correspond to a separate tool, utility, or program in your project. Each of these subdirectories can have its own `main.go` and specific dependencies. These subdirectories act as executable “commands” in the project and are the main input for starting different parts of the application.

Internal

The internal directory is used for packages that should only be accessible from the module in which they reside. This means that these packages are only for internal use within your own project and should not be imported by other external projects. This structure helps maintain tighter encapsulation and reduces coupling between different parts of your application.

In other words, the code inside internal is meant to be private to the project itself.

pkg

The pkg directory is similar to the internal directory but with one key difference. The packages inside pkg are designed to be exported and used by other external projects.

If you have reusable components or utilities that may be useful to other projects, you can place them in this directory. These packages can be imported and used in other projects thanks to the use of go modules.

It is important to note that these conventions are widely accepted in the Go community, but are not mandatory. You can customize the structure of your project according to your needs and preferences. However, following these conventions can make your code more clear, maintainable, and understandable to other developers who are familiar with these common practices.

The microservices packages based on DDD

The Domain-Driven Design (DDD) structure that will be implemented to organize our code is based on the following packages:

root-folder/
├── cmd/
└── internal/
    ├── app/
    │   └── api
    │      ├── dto
    │      ├── handlers/
    │      └── services/
    ├── domain/
    ├── infrastructure/
    │   ├── persistence/
    │   └── database/
    └── shared/
        ├── logger
        └── errors/

Let’s describe a bit each one of the packages inside of internal:

internal/app/api

This package houses the application-specific logic, including controllers, services, and any other components that are directly related to the implementation of the application. It provides an intermediate layer between the high-level logic (domain) and the technical details (infrastructure), allowing business logic to communicate with external interfaces (controllers, APIs, etc.).

internal/app/api/handler

Contains the controllers that handle HTTP requests or user input and turn them into actions in the application.

internal/app/api/services

In this package reside the application services, which implement the business logic. Services can be made up of more complex operations that involve interactions between various entities.

internal/app/api/dto

These DTOs encapsulate specific data required for concrete operations and can include validations and transformations. Furthermore, they are documented and tested to ensure their proper functioning. Their main objective is to enable a clear separation of responsibilities and enhance efficiency in communication between application layers.

internal/domain

This package contains the main entities of the domain. It defines and encapsulates the core business logic in data structures with related behaviors. In this package, you will find implementations such as entities, value objects, services, etc.

Internal/infrastructure/persistence

This package is used to implement the repositories that interact with the storage layer (database, memory, etc.) to retrieve and store data. This package abstracts access to the storage layer and allows data access concerns to be separated.

internal/infrastructure/database

This package contains the specific implementation for connecting and accessing the database.

internal/shared/errors

Defines custom errors that can occur in the application. They can include application errors (for example, incorrect user input) and business errors.

This organizational structure follows the principles of DDD, where business logic is separated from technical concerns and organized into entities, aggregates, services, etc. The modular and well-structured approach makes it easy to scale and maintain as the project grows.

Next readings …

Wait for Chapter 11“Building a Microservice With Go — Coding our Microserivice ”.