DEV Community

loading...

Discussion on: Introducing Gate Classes (Design Pattern)

Collapse
raimeyuu profile image
Damian Płaza

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 :-)

Collapse
jamesmh profile image
James Hickey Author

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:

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! 👍