You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Hi,
Really love the series (awesome job!), but I struggle to figure out how to design a way that would let someone who wants to use a specific use-case know which all different errors, causes, can be encountered, without the need for the caller to be familiar with business rules governing the use-case.
In your examples, you both declare causes in use-case specific error interfaces and set them as private constants in value objects, thus making them hard to interpret/translate to custom "outside" world responses in the adapter leafs.
For instance:
In your example of REST Controller, the REST adapter is translating the ProfileErrors to specific responses.
This approach would be great if all causes are captured in the ProfileError interface, but in the example for ValidRequest each value objects defines its own private causes.
The value object Password has a business rule Password must contain uppercase letter but if I wanted to translate the cause MISSING_UPPERCASE to a 400 BAD REQUEST response, how would the REST adapter do that, or to be more precise, how would the REST adapter (user of the use-case) even know that such causer/error was a possibility?
Since the value objects can be part of shared domain, they can't return some use-case specific cause, so should every call to a value object in a use-case be followed by a .mapError() call that would translate the value object's cause to a use-case specific error/cause? So this way we can gather all possible business errors for a specific use-case at one place? Or do you have a better approach in mind?
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
Hi,
Really love the series (awesome job!), but I struggle to figure out how to design a way that would let someone who wants to use a specific use-case know which all different errors, causes, can be encountered, without the need for the caller to be familiar with business rules governing the use-case.
In your examples, you both declare causes in use-case specific error interfaces and set them as private constants in value objects, thus making them hard to interpret/translate to custom "outside" world responses in the adapter leafs.
For instance:
In your example of REST Controller, the REST adapter is translating the
ProfileErrors to specific responses.This approach would be great if all causes are captured in the
ProfileErrorinterface, but in the example for ValidRequest each value objects defines its own private causes.The value object
Passwordhas a business rulePassword must contain uppercase letterbut if I wanted to translate the causeMISSING_UPPERCASEto a 400 BAD REQUEST response, how would the REST adapter do that, or to be more precise, how would the REST adapter (user of the use-case) even know that such causer/error was a possibility?Since the value objects can be part of shared domain, they can't return some use-case specific cause, so should every call to a value object in a use-case be followed by a
.mapError()call that would translate the value object's cause to a use-case specific error/cause? So this way we can gather all possible business errors for a specific use-case at one place? Or do you have a better approach in mind?Beta Was this translation helpful? Give feedback.
All reactions