Void Or Other Result In DDD Operation

If your addBook method is designed so that it will always succeed, a void is preferred. If your method does validation on book, then returning a result is better then handling it with exceptions.

In my opinion, exceptions should be used for exceptional situations only; if a database or webservice is down, throw an exception, but if the title should be unique and it isn't, I would not throw an exception but return a result.

This sums it up nicely:

The method is a command and it can’t fail:

public void Save(Customer customer) 

The method is a query and it can’t fail:

public Customer GetById(long id) 

The method is a command and it can fail:

public Result Save(Customer customer) 

The method is a query and it can fail

public Result<Customer> GetById(long id) 

Source: https://enterprisecraftsmanship.com/2015/03/20/functional-c-handling-failures-input-errors/

Further reading: https://martinfowler.com/articles/replaceThrowWithNotification.html

The prevailing idiom in object-oriented languages is to return void.

The reason being, that callers expect methods to be composable through sequencing, that is, writing them after each other, separated by semicolon (;). It would be just be too much repetitive work to have a condition after each method invocation to check whether it succeeded or not (just look at C). That's why there are Exceptions.

So make it void, and throw an Exception if there is something wrong, otherwise the caller should assume the operation succeeded.