Test application design + folder package structure to achieve a clean web application that is testable and without strong uncoupling.
- Version 2: https://www.reddit.com/r/golang/comments/91a54y/proper_structure_for_a_dependencyinjection_based/
- Version 1: https://www.reddit.com/r/golang/comments/8zn2ti/how_to_handle_dependency_injection_and_mocking/ (old)
This system contains three "databases" to show how easy it is to swap stores when using DI:
/mock(Fake backend, for testing)/mysql/ledis(like redis, but in-process like sqlite)
Currently the only test (/mock) in here is pointlessly testing itself. How should this be refactored? Should the tests be placed next to the implementations and only use the /mocks?
How will this approach work with 20+ domain objects (users,likes,comments,etc...)? At the moment the /mysql implementation of UserService has all the possible database queries defined on itself with no separation. Should UserService become a monolithic StoreService or should we add 20+ more ___Service interfaces?
This same question goes for the http handlers and other possible API's such as GraphQL.
Mattermost is an example that defines a base store that wraps all the individual entity store interfaces. Then provides sql and other concrete implementations of these interfaces for actual storage. This includes a mock store.
- Standard Package Layout
- Interface Location
- Wrap sql.DB and sql.Tx
- HTTP Closures
- Simple Go Server
- Dependency injection
- HTTP middleware
- Discussion on passing db to http.Handlers
- Should I mock the DB?
- http.Handler wrapping
- Golang UK Conference 2016 - Building an enterprise service in Go (video)
- Exploring DDD in Go