I am trying to standardize an architecture for my Go projects, so I have a
file structure like this:
├── go.mod
├── go.sum
├── internal
│ ├── domain
│ │ ├── models
│ │ │ └── user.go
│ │ └── services
│ │ └── user.go
│ └── repositories
│ └── mongodb
│ ├── base.go
│ ├── config.go
│ └── user.go
File services/user.go:
https://go.dev/play/p/ZYWhgHRLU5V
In the services I have business logic and in another folder called
repositories I have implementations in different technologies as needed.
For example I can have an implementation of UserStore in Mongo DB... or
Postgres etc.... And the idea is then to have a layer on top of these
services... that can be, an APIRest, a serverless etc....
I have doubts about where I should define the errors in my system. For
example, a common error could be *ErrRecordNotFound*, but depending on the
repository/technology, this error will be different.
I was thinking of defining the errors inside the domain folder, and then in
the repositories, the errors are mapped to my domain errors.... for example
if it was in mongo, my code would look like this:
if errors.Is(err, mongo.ErrNoDocuments) {
return nil, domain.ErrDocumentNotFound
}
(or in some cases wrap the library specific error in my domain error).
This way my business logic would not depend on specific technologies, but
the implementations/libraries depend on my business logic. A possible
disadvantage is that my repositories code may no longer be reusable because
it is “smeared” with specific business logic.
Is this approach correct? Or should I approach it differently?
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion visit
https://groups.google.com/d/msgid/golang-nuts/85b7fa7d-1c01-4281-be20-4837f6019743n%40googlegroups.com.
