Closed blaggacao closed 3 years ago
I'm implementing #11 under this assumption to be true.
Hi @blaggacao. You're right that the state in the database should always be valid. In the rare case it isn't, you need to decide whether you'd like to deal with proper errors (possibly wrapped in outer layers) or with panics.
We usually try to use panics only for exceptional cases. For example, it's fine to use the Must
constructor in tests, for the added code readability. However, in the application we'd like to have all errors clearly reported.
Got your point!
One could also argue that an inconsistent repository state (as part of the infrastructure layer) from the domain's perspective is indeed comparable to a memory access violation which would support a panic
.
On the other hand, my proposal does not cover for corruption in "private" fields (the ones that are not constructable through New
). Hence it's not 100% consistent in it's current form.
Closing as a springboard for further analysis.
https://github.com/ThreeDotsLabs/wild-workouts-go-ddd-example/blob/186a2c4a912e485ac7bb4d18c2892df7617e9ec9/internal/trainings/domain/training/training.go#L51-L61
Shouldn't it be adequate to use
NewMustTraining()
when unmarshaling from the repository?In my reading that would support the notion that we should afford to assume from the domain that the repository does its job and does not get magically corrupted.