Quite the opposite, really.
Observer pattern has been so useful some languages and frameworks embraced it as first-class primitive. Events in C# being prime example.
Observer pattern can also be found on architectural level, where services can subscribe to events produced by other services.
But the real question is if observer and pub-sub patterns are ...
There are use cases for both exceptions and result objects, so "cleanliness" of the code is dependent upon the use case. It all depends on how critical it is to stop the execution of the program.
Exceptions are the hand grenades of programming. Pull the pin and throw it. The only thing to keep your application from blowing sky high is to catch it and handle ...
Observer pattern is fine for smaller programs. As you mentioned, it properly decouples the event from the class which acts on that event.
However, wiring it up can get a bit complex, and although the event itself is decoupled, wiring up the event still requires that at least at some point, the observer must know about the subject.
So generally the ...
the recommendation is to prefer returning a result object than
throwing an exception
This is bad advice IMHO, because they should be used in different circumstances. Using a result object when an exception is most appropriate is bad.
If ValidateUserInput is not able to perform its task because (for example) the process is out of memory, then throwing an ...
Recently come across this due to my own issues so I'll add my own $0.02. Since as others have pointed out this does not mutate the Aggregate Root (AR), it's not a Command and therefore should be handled on the query side.
My feeling is that the options are to do the calculation in:
The API (service layer) by querying the AR after (hydrating it)
The API (...
The pattern itself doesn't violate the Open/Closed Principle (OCP). However, we violate the OCP when we use the pattern incorrectly.
The simple answer to this question is as follows:
Create your base functionality using Factory Method Pattern.
EXTEND your functionality by using the Abstract Factory Pattern
In the provided example, your base functionality ...
Methods which throws exceptions are not "honest". You can't recognize if a method is expected to fail or not, by looking at its signature.
Compared to [older versions of] Java this was argued to be one of .Net's biggest failings. Java laces Exceptions right into the Method signature; .Net doesn't.
Exception handling adds a lot of boiler plate code.
Don't do premature optimization. Filtering reviews based on the ID of a user takes microseconds: I'm pretty sure the bottleneck in your app is at somewhere else.
Query the review of the current user, and show it immediately, as the user may be interested to know as soon as possible that he already reviewed the entity. Then, do an AJAX request to get the ...
I would lean towards Approach 1, with one modification. EmailService does not need to know the concept of a User.
Two points to further clarify:
By forcing EmailService to know about the concept of User, you are potentially opening yourself to the high-effort task of keeping the service in sync with potential changes across different bounded contexts. ...