Question: Should Mappers returns Result<T> signature?

[roylee0704]

white-label/src/modules/vinyl/mappers/VinylMap.ts

Line 18 in 8d18135

return vinylOrError.isSuccess ? vinylOrError.getValue() : null;

Is there is a reason why it's not returning Result ?

[apparatusdeus]

I'd guess it's to simplify code in other areas. Otherwise every time you load an item from your persistence layer you'd have to perform error checking but I've actually gone down the route of returning Result objects from the Mapper functions.

[NikitaIT]

@roylee0704
Domain should always be in the persistence state. If we allow the software to continue working after an error in domain model, it may come into an invalid state, and save that state to the database.

Domain classes must throw an Exeption, for fail fast principle(FailFast @ MartinFowler).

Result monad is well suited for validating data before it is passed to domain class methods.

If an invalid state is passed to Mapper, and if this is the expected case, for example, when we added a new required field to the database, but only users can fill it out, we need to create an additional field, for example, CustomerOld, and wait for the moment when we can delete it without causing exceptions.

[apparatusdeus]

@NikitaIT I have to disagree with you.

I think you are misinterpreting fail fast principle as "must throw an Exception", even in the document you have attached, Matrin Fowler's main complaint is returning partially correct or default values that allow the system to continue operating in an invalid state.

I believe that the Result class handles the principle in the same was as an exception without destroying the fluidity of the system. You are not able to act on a failed Result object in the same way as the object type and your code is forced to handle it unlike exceptions which are frequently overlooked, undocumented and badly handled.

Either way, the current implementation within the project of returning a null value on the bad mapping neither fails nor is it visible.

[NikitaIT]

@apparatusdeus
Let me explain, when we throw an exception we say "the code that we wrote does not seem to work correctly", when we return Result we say "the code works correctly, but we expect the operation to be processed with an error."
When we write code in entities, we say "this method should only be called with arguments appropriate to the contract, if this is not so, then I wrote the code incorrectly." Using Result, we actually delegate the decision on whether we are using the method correctly or not, this gives us the opportunity to ignore the error. Virtually all domain model methods become tryDoSomething.

This is similar to "First think, then speak" for code. This makes it possible to validate only IO, and as soon as the data crosses the boundary, we can trust the code, instead of trying.

• Result assumes a possible recovery reaction at the place of the method call.
• Fail Fast does not expect to restore the current task within the current context.