Would it be good practice to separate a user entity and a user profile entity?

Question

When designing a system that displays information about an entity (but where modification of the data is rare or restricted to few users - such as a user profile), would it make sense to have two separate classes to do this?

One for management of a user profile (logging in, changing password, modifying profile content) and another purely for the consumption of this data (a UserProfile/UserView) which can only retrieve the displayed data for the user.

1. Is this a sensible choice to make?
2. Would there be any security reasons in this style of architecture?
3. Would this violate the concept of modelling an entity as a single class? (and are there instances where this is acceptable/expected?)
4. Are there any common patterns or best practices for modelling an entity in this way?

Let's work on the assumption that this is a social media profile.

Answer 1

To answer your question, there are several aspects to think about.

Depending on how you see the user, the user-Information could be modeled as part of the userprofile or the other way around:

user = {
         "lastname": "Doe",
         "firstname": "John",
         "id": "a972f435-5263-401a-a03b-950e9e0e29c1",
         "birthday": "1970-01-01"
       }

There is nothing wrong with this kind of data. If you use a backend capable of dealing with JSON, you could store it right away.

On the other hand, depending on how detailed your user is, it makes sense to separate user-data from profile-data; or perhaps you have the need to use different databases for different purposes: say, you have a login-service which serves the only purpose to log in users - in such a scenario it makes perfectly sense to have your user in one place and the profile in another (perhaps you are using MongoDB or something like that).

Is this a sensible choice to make?

There is no general solution to that. It is a rather philosophical question without context. A nice topic for a scholastic discussion about architecture.

Would there be any security reasons in this style of architecture?

Unfortunately I am no security expert to give you a detailed answer to that. You have to secure your system anyways. From a security perspective it could make sense to split between user and profile or better: user, profile, creditcard-data in three different databases. But that is a naive guess. There are people who are better at security than me ;)

Would this violate the concept of modelling an entity as a single class? (and are there instances where this is acceptable/expected?)

Are there any common patterns or best practices for modelling an entity in this way?

As said from the above: there are reason to handle it one way or the other. I would go with as long as you have no reason to really split the data, keep it all together. Look for simple solutions in the first place and evolve your system alongside with your needs.

Answer 2

User and UserProfile are different entities in the same way User and BankAccount are different entities.

In the case of displaying info, each entity has the responsability of displaying it's info, although User can delegate part of its displaying reaponsability to its UserProfile.