I'm personally using CQRS and Event Sourcing now so my perspective may be a little different but here's my thoughts.
Firstly the simple stuff, I notice you're using 'signature' attributes similar to Sharp Architecture - personally I don't see the need for them. I know why you use them, but two User entities will never be equal anyway because their id's will be different, and you're still going to run some kind of check to see if that username exists in your database when the entity is transient. Similar for the Role entity, I'd remove the signature, perform the checks you'd perform anyway and just add the unique constraint when mapping it. I guess if they're part of your Entity base class and it's comparison methods it's not worth the hassle changing that though.
I'd also remove (or use the protected modifier for an ORM) the public setters on the Password and Email fields. I couldn't think of any scenario where you'd create a new User without a password at least, even a predefined password would contain either no characters or 'password' etc. I'd set them in the constructor and have ChangePassword(), ChangeEmail() methods.
As for the Role, I guess it depends on your end-user perspective. Is the User going to assign a role to themselves, or are you going to assign a user to a role. In most cases you're probably going to have some form of super user who assigns users to roles, in which case a Role.AddUser(IUser) would seem the more likely option. I'd take a look at this article that discusses a pretty similar problem, http://www.udidahan.com/2009/01/24/ddd-many-to-many-object-relational-mapping/.
A job can be posted to multiple job boards. And a job board can have multiple jobs posted. A regular many to many relationship.
While we could just leave the bi-directional/circular dependency between them, it would be preferable if we could make it uni-directional instead. To do that, we need to understand their relationship:
If there was no such thing as “job”, would there be meaning to “job board” ? Probably not.
If there was no such thing as “job board”, would there be meaning to “job” ? Probably. Yes. Our company can handle the hiring process of a job regardless of whether the candidate came in through Monster.com or not.
From this we understand that the uni-directional relationship can be modelled as one-to-many from job board to job. The Job class would no longer have a collection of Job Board objects. In fact, it could even be in an assembly separate from Job Board and not reference Job Board in any way. Job Board, on the other hand, would still have a collection of Job objects.
Going back to the code above we see that the right choice is jobBoard.Post(job);
If you're starting over I'd personally spend a couple of hours reading up on CQRS, it might seem like a lot of extra work at first but I've found the opposite.