I have a critical business object GroupMembership that represents the relationship between an user and a group. I have set an architectural policy that critical business objects should avoid referencing each other directly, and instead only represent their dependencies with minimalistic interfaces. The goal of this is to promote easy unit testing and minimize coupling.

public class GroupMembership
    public GroupMembership(Guid id, IIdentity group, IIdentity user)
        Id = id;
        Group = group;
        User = user;

    public Guid Id { get; private set; }
    public IIdentity Group { get; private set; }
    public IIdentity User { get; private set; }

However, in this class, adherence to this rule seems a bit legalistic; currently, it does not even have any behavior to unit test anyway. On the other hand, breaking this convention myself may provide a bad precedent for the other developers on the project, whom may not be as understanding of architectural principals.

Am I going overboard here? Or will sticking to the rules I set help the project maintain architectural conformance? Are direct relationships a known exception to using only virtual references?

  • You probably want to enforce that group identifies a Group. What does IIdentity contain?
    – Caleth
    Commented May 2, 2018 at 13:18
  • @Caleth Name, GetAssignedAssets Commented May 2, 2018 at 13:44

1 Answer 1


The reason for avoiding concrete references is to avoid coupling functionality. GroupMembership is just a value object though; it has no functionality. Therefore you gain nothing by abstracting the reference to such values and just create an overhead instead.

So yes, you would be going overboard if you applied your "critical business objects should avoid referencing each other directly" to value objects. So your code is fine as is (save for the pointless private set; statements; they haven't been needed since C# 6)

  • Well... the above code uses interfaces instead of the actual class name, which you said was not needed. So I am confused by your answer Commented May 2, 2018 at 15:23

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.