Example of the application of layered architecture style in go.
This application is based on the post.
File structure is...
$ tree $GOPATH/src/example.com/layered-arch-in-go
.
├── cmd
│ └── app
│ └── main.go
└── user
└── user.go
The point is...
- factory methods like
NewXXX
should return concrete type. - if you wanna use transaction, check if the repository satisfy the sqlDB interface or not.
Pros
- Repositories in infrastructure layer don't need to know the interface of
Repository
- less objects (without connection object)
Cons
- need type assersion
repo.(sqlDB)
in all application method- But, I think, it might be a long time before you wanna switch another infrastructure.
自分はどうしているのかというと、 インフラレイヤの差し替えは考慮して実装していない。 差し替えが発生した場合、アプリケーションレイヤの修正も発生するのは仕方ないと思っている。
差し替え対象によって考慮する要素が替わってくるし、 差し替えが発生するかどうかも分からないので、 必要になった際にそれなりの工数をかけるのがシンプルな気がする。 もちろん、直近で想定されるのであれば、それなりの仕組みを実装するのがいいかもしれないが・・・。
👍