Hi Setya,

{quote:Setya}
From your example about Library system, is it really LibraryUser's responsibility to validate number of reserved books / book reservation status? Shouldn't we add another domain model called LibraryOfficer to do the validations ?
{quote}

You've put up a interesting question, the logic you are pointing out is actually domain logic from the relation between LibraryUser and Book not the LibraryUser or Book entities itself. 

I wouldn't go for another entity that would just validate, because it's something that the relation between the two objects, LibraryUser and Book, should be able to tell by itself.

In my opinion, there are various approaches to deal with these cases, one is to actually put the relation logic coupled to nee of the ends of the relation - which was what I did in this example- (attention, not saying it's the best way), use listenners or generate a "relation class" for each class that actually contains semantic.

The first approach you already seen it, because it's the one I presented on the example on the comments.\\
The second approach, is to create a listenner on the relation - using for example the {link:Observer Design Pattern|url=http://en.wikipedia.org/wiki/Observer_pattern} and check the domain login when the relation is changed. 
Finally the third one, where the relation itself is a entity, this happens because, as you identified the relation as logic. So we would have a new entity named __Loan__ where the constructor would, for example, look like:

{code}
public class Loan extends DomainObject {
  public Loan(LibraryUser user, Book book) {
     if (getReservedBooks().size()>2 || book.isReserved()) {
      throw new DomainException("error"); 
     }
     user.getReservedBooks().add(book);
  }
}
{code}

The idea is that Library stops having a direct relation with book, but actually with Loan. So:

* LibraryUser as a __1 to many__ relation with Loan.
* Book as a __1 to many__ relation Loan.

And all the logic regarding the relation stays in the Loan class.