Repositories

The Repository Pattern

The repository was introduced as part of domain-driven design (DDD). It is an object responsible for the logic that stores and retrieves data. Through a repository, the domain layer can receive simply abstracted objects independently of how data is stored in the database. This lets consumers add, update, and delete items without worrying about database connections or SQL statements.

How It Differs from a Factory

A factory creates objects in memory. A repository is closer to reconstituting existing objects. An object created by a factory can be stored through a repository and later reconstituted when needed.

Declaring and Implementing a Repository

Declare repository interfaces in the domain layer and define their implementations in the data layer. This makes domain logic easier to test and reduces the impact that changes in one layer have on another.

Building and Using Repositories

This section uses the Order Aggregate example from Design the infrastructure persistence layer.

Project Layout

Use the following project layout as a guide. It is only an example: you may adapt it as long as you preserve feature-oriented packaging and the clean architecture dependency rule.

.
└── order
    ├── entity.go
    ├── repo
    │   └── repo.go     # Repository Implementation
    ├── repo.go         # Repository Interface
    ├── usecase.go
    └── valueobject.go

A Repository’s Responsibilities

Update the database only through repositories. Use one repository per aggregate root and structure each operation as a Unit of Work. A unit of work can generally be thought of as a single transaction. Changes to entities and value objects are made in the domain layer; the data layer, including repositories, focuses on persisting those changes.

The Order entity defined in order/entity.go is an aggregate root and has a single repository. Access its child entity OrderItem and value object Address through the Order repository, even if they occupy different database tables.

Multiple Data Sources

Working with one aggregate root may require multiple data sources. A repository is part of model-driven design; it is not defined by the characteristics of the database. Having multiple databases therefore does not, by itself, justify defining multiple repositories.

To use multiple data sources in one repository, define data sources in the data layer. The repository combines data from those sources to create the required object. For example, it may contain logic that combines MySQL and Redis data to reconstitute an Order object.

Object-Relational Mapping (ORM) Tools

You can use an ORM tool when working with a relational database. ORMs define table mappings on objects, and sometimes multiple models need to access the same mapped object. In that case, place the mapping code in a separate, independent package and have repositories use it.

.
├── rdb
│   └── schema.go
└── order
    ├── repo
    │   └── repo.go
    ...

Define the ORM objects in rdb/schema.go. In order/repo/repo.go, use the ORM and rdb package to access the database, then reconstitute entities from the resulting data.

schema.go

type Profile struct {
    ID        int64 `gorm:"primary_key"`
    // ...
}

repo.go

var p rdb.Profile
if err := r.db.First(&p).Error; err != nil {
    return nil, err
}

References

• Microsoft Infrastructure Persistence Layer Design
• Repository Pattern
• Tactical Domain Driven Design
• Domain-Driven Design