Differentiate application exceptions

[alexeyzimarev]

Related to #77

@thomaseyde describes that the application service fails when handling a command when an event stream contains an unknown event. Currently, the app service returns an ErrorResult where the exception is "unknown event type".

The reason for the app service to return an ErrorResult in the first place was to convey domain-level errors to the caller. However, things like "event store is down" or "unknown event type" are different types of errors as they indicate technical failures rather than model issues.

I am now inclined to make the application service throw on technical errors during Load and Store, but keep returning the ErrorResult when an exception is thrown when handling the command itself.

[diegosasw]

I know the command service does not throw exceptions and instead returns Result.
What about errors at aggregate level? Is the recommended approach to model them as additional domain events? to throw DomainException that command service will handle and transform into Result? or is there any other way to embrace Result pattern also at aggregate level?

[bartelink]

TL;DR Forcing people into the Result pattern invariably makes a mess, regardless of the language and idioms that generally apply in a consumption context. Remove!

Infra errors should throw, and decision function's should return BOTH:
a) events, regardless of success/failure
b) a result, regardless of whether it's an array of validation errors, a Result type, or Unit (aka Void)
This is because infra issues (and testing of same), producing event (and testing of that), and domain errors (and testing of that) are ALL otrhogonal concerns - yes it apprears you can abstract everything into an elegant lowest common denominator when the problems are basic, but it simply does not scale in terms of handling complexity.

[alexeyzimarev]

I talked to Jérémie about it some time ago. He said the domain model should throw as the request was invalid and it should be explicit. Essentially, from the API side it will result in 400.

That's what Eventuous HTTP API is doing. The requirement is that the model needs to throw a DomainException.