I'm trying to design a database model for an API. So far, here's my attempt to do so:

I have a package called models that contains all of the models. Here, User is the database model and UserStorer is an interface that should be implemented by any store (e.g. postgres, mongodb etc.)

package models

//User represents an application user
type User struct {
    ID         int64
    Email      string
    Password   string
    FirstName  string
    MiddleName string
    LastName   string


//UserStorer represents a user store
//this can be used to store user on different
//data store
type UserStorer interface {
    List(...UserFilter) ([]User, error)
    Get(...UserFilter) (User, error)
    Create(User) error
    Update(User) error
    Delete(...UserFilter) error

Then I have a package called store, which contains the implementations of model stores like UserStorer

package store

import (


//UserStore implements models.UserStorer
type UserStore struct {
    db *sqlx.DB

func (cs *UserStore) List(filters ...models.UserFilter) ([]models.User, error) {
    return nil, nil

func (cs *UserStore) Get(filters ...models.UserFilter) (models.User, error) {
    return models.User{}, nil

func (cs *UserStore) Create(User models.User) error {
    return nil

func (cs *UserStore) Update(User models.User) error {
    return nil

func (cs *UserStore) Delete(filters ...models.UserFilter) error {
    return nil

func NewUserStore(db *sqlx.DB) models.UserStorer {
    return &UserStore{db}

The question is, am I doing it right? If not, how do I improve it?

Here is the repo of the example that I used: https://github.com/steven-ferrer/go-db-models

  • \$\begingroup\$ Did you test it? Did it work? It looks good to me, but testing might show you where things need to be adjusted. \$\endgroup\$
    – Benjam
    Oct 6, 2017 at 21:19
  • \$\begingroup\$ I've tried implementing a UserStore using postgresql as database and it worked fine. I just need to know if i'm on the right direction or if there are anything that I can improve on this. \$\endgroup\$ Oct 7, 2017 at 4:59

1 Answer 1


I like your approach:

  1. First you've defined an interface on accepting side of application. So you can fix requirements to parts responsible for storage.

  2. Realisation is not tied to interface. Today you may use PostgreSQL, later you may add some sharding on application side, or even migrate to another DB. Keeping db-related logic in one place helps you do it in future.

  3. Next you can cover it with tests to ensure logics won't get broken in future impovements.

  • \$\begingroup\$ my first idea was to store each model on a separate package, say the import path would be example.com/foo/models/users, then you would have users.User, users.Filter users.FilterConfig, users.Store. Do you think it would make sense? \$\endgroup\$ Oct 7, 2017 at 6:07
  • 1
    \$\begingroup\$ Depends on application and how components are tied together. I think it's ok group models by domains: separate users and objects an so on. And if you need some submodules place subpackages in them/ \$\endgroup\$ Oct 7, 2017 at 6:18
  • \$\begingroup\$ i'm not sure if i completely understand your suggestion, could you please give a concrete example? \$\endgroup\$ Oct 7, 2017 at 6:21
  • \$\begingroup\$ Unfortunately can't show an example at a moment ( I mean to keep together. It's good to start as you proposed with users.User etc. An then when it will be necessary group in bigger packages. \$\endgroup\$ Oct 7, 2017 at 8:28

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.