search

ThreeDotsLabs / wild-workouts-go-ddd-example

Go DDD example application. Complete project to show how to apply DDD, Clean Architecture, and CQRS by practical refactoring.
https://threedots.tech
MIT License
5.14k stars 472 forks source link

Must.. for unmarshaling from repository #13

Closed blaggacao closed 3 years ago

blaggacao commented 3 years ago

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.

blaggacao commented 3 years ago

I'm implementing #11 under this assumption to be true.

m110 commented 3 years ago

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.

blaggacao commented 3 years ago

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.