backend/

README

Resource Service

Architecture Overview

The code follows Clean Architecture as described by Uncle Bob.

Entities Layer

The innermost layer, is the entities layer found in the entity package:

Entities encapsulate Enterprise wide business rules. An entity can be an object with methods, or it can be a set of data structures and functions. It doesn’t matter so long as the entities could be used by many different applications in the enterprise.

In this package we have the definition of our entities, and their respective unit tests.

Use Cases Layer

According to Uncle Bob:

The software in this layer contains application specific business rules. It encapsulates and implements all of the use cases of the system

Inside the usecase package, we implement the other business rules of our product. We also find here the mocks generated by Gomock. The outermost layer of the architecture will use them during the tests.

Frameworks and Drivers layer

According to Uncle Bob:

The outermost layer is generally composed of frameworks and tools such as the Database, the Web Framework, etc. This layer is where all the details go.

For example, in the file infrastructure/repository/user_keyvalue.go we have the implementation of the interface Repository for a KeyValue Store. If we need to change to another database, this is where we would create the new implementation.

Interface Adapters Layer

The codes in this layer adapt and convert the data to the format used by the entities and use cases for external agents such as databases, web, etc.

In this application, UseCases are accessed through an HTTP API.

The api package is divided into three packages: handler, presenter, and middleware.

The handler package handles HTTP requests and responses, as well as using existing business rules in the usecases.

The presenters are responsible for formatting the data generated as a response by handlers. This gives us control over how an entity will be delivered via the API.

In the last package of the API we find the middlewares, used by several endpoints, implementing cors and metrics.

Support Packages

Support packages inside pkg, provide common functionality such as encryption, logging, file handling, etc. These features are not part of the domain of our application, and all the layers can use them. Even other applications can import and use these packages.

Go dependencies

The go dependencies for the Metadata-Service are defined inside the go.mod and the corresponding go.sum files. To be able to use external dependencies with Bazel, all external dependencies need to be registered with Bazel so that they can be referenced in the BUILD.bazel files.

The steps to add an external dependency are as follows:

1. add repository and version to go.mod
2. from inside this directory, run go mod download gihub.com/stretchr/testify (exchange the name of the package with the one you would like to add)
3. from the root of the repository, run make resource-gen-deps

Running the make metadata-gen-deps will regenerate the deps.bzl file found in the root of the repository. This file is loaded inside the WORKSPACE file, so that Bazel can go and fetch the external repositories and make them available to be used in rules.

From then on, you should be able to use the external dependency in a BUILD.bazel file like so:

go_test(
    name = "entity_test",
    srcs = ["organization_test.go"],
    embed = [":entity"],
    deps = ["@com_github_stretchr_testify//assert"],
)