 <p>I agree with guillaume31 that there is no need to introduce a domain object "UsersPerPermission" to support a single use case. </p> <p>There are two ways you can implement your use case using existing domain classes "User", "Role" and "Permission".</p> <hr> <p>Solution one:</p> <p>Assume you have: Permission --> Role --> User</p> <p>Arrow denotes navigability. A Permission has association to a list of Roles and a Role has association to a list of Users.</p> <p>I would add a method <code>GetPermittedUsers() : List&lt;User&gt;</code> to the Permission class, which is trivial to implement. </p> <p>Th UI logic will invoke GetPermissions() of PermissionRepository then call GetPermittedUsers() on each Permission.</p> <p>I assume that you use a ORM framework like hibernate(Nhibernate) and defines the many-to-many relationships correctly. If you defines eager loading for Role and User from Permission, the ORM will generate a query that joins Permission, Role and User tables together and load everything in one go. If you defines lazy loading for Role and User, you will load a list of Permissions in one query when you call PermissionRepository, and then load all associated Roles and Users in another query. Everything is load from database with up to three queries maximum. This is called a 1+n problem which most ORMs handle properly.</p> <hr> <p>Solution two:</p> <p>Assume you have: User --> Role --> Permission</p> <p>Arrow denotes navigability. A User has a list of Roles. A role has a list of Permission.</p> <p>I'd add <code>getUsersByPermissions(List&lt;long&gt; permissionIds) : List&lt;Users&gt;</code> to the UserRepository, and add <code>getPermissions() : List&lt;Permission&gt;</code> to the User class.</p> <p>The implementation of the UserRepository need to join the User, Role and Permission tables together in a single query and load everything in one go. Again, most ORMs will handle it correctly.</p> <p>Once you have a list of Users, you can create a method to build a <code>Map&lt;Permission, List&lt;User&gt;&gt;</code> quite easily.</p> <hr> <p>To be honest, I muck like the solution one. I avoid to write a complicate method to convert a List of Users to to a map of Permission and Users, hence I don't need to worry about where to put this method. However solution one may create cyclic relationship between User, Role and Permission classes if you already have navigability in another direction. Some people don't like cyclic relationship. I think the cyclic relationship is acceptable even necessary sometime if you user cases demand it.</p>