Thanks for sharing this pattern, looks really interesting. However, I feel worried about Invoke method signature of such Gate class. It communicates it's async and does not return anything (by returning Task) while in fact it implicitly throws exceptions here and there. I know that having a global exception handler is common practice, but I don't feel it's the best what we can do.
In fact, such Gate approach is quite common in functional programming, but it's encoded in method's signature by using Result type. Here's a good explanation with showcase of such approach: enterprisecraftsmanship.com/2015/0...
Specifically, in one section, I mention that one possible alternative is the Result Object pattern, which is basically the pattern used in the link you provided.
So I agree, sometimes it might make more sense to use some custom class or "error" data structure to pass back and forth.
This article is great on the subject. It looks at 3 different ways to do this actually. While my conclusions are the exact same as his, he gives more details for why, whereas that wasn't an issue I specifically was tackling in my article, but just mention it in passing.
It's common in DDD due to the fact of using Value Objects and the "Always Valid" pattern, essentially.
Let me know what you think! 👍
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Thanks for sharing this pattern, looks really interesting. However, I feel worried about Invoke method signature of such Gate class. It communicates it's async and does not return anything (by returning Task) while in fact it implicitly throws exceptions here and there. I know that having a global exception handler is common practice, but I don't feel it's the best what we can do.
In fact, such Gate approach is quite common in functional programming, but it's encoded in method's signature by using Result type. Here's a good explanation with showcase of such approach: enterprisecraftsmanship.com/2015/0...
I am curious about your opinion :-)
Throwing exceptions in the non-application layer is a convention that some people just plain detest, and some find is just more pragmatic.
I wrote about this a bit in this article:
Where Do I Put My Business Rules And Validation?
James Hickey
Specifically, in one section, I mention that one possible alternative is the Result Object pattern, which is basically the pattern used in the link you provided.
So I agree, sometimes it might make more sense to use some custom class or "error" data structure to pass back and forth.
This article is great on the subject. It looks at 3 different ways to do this actually. While my conclusions are the exact same as his, he gives more details for why, whereas that wasn't an issue I specifically was tackling in my article, but just mention it in passing.
It's common in DDD due to the fact of using Value Objects and the "Always Valid" pattern, essentially.
Let me know what you think! 👍