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