Best practices to link, associate, or abstract similar but different entities together

Question

What are the best practices that I can follow that can simplify or help abstract out entity modeling when there are many similar but different entities?

I have a large game system with different types of accounts representing an end user, but they are all distinct & isolated.

To name a few,

• The system has a concept of user accounts which are created when people register on the game website.
• It has a concept of "players" which are created separately. Players can be associated with "users", but not necessarily all the time. The game is playable without registering on the website.
• It also has a concept of "observer" which is only created when users want to observe a game.
• The system has an older version of the game, still generating a substantial part of revenue. This classic game mode has its own user management system.

Each component was created a while back by separate software consultant agencies or outsourced developers, so they didn't have a holistic view and only focused on creating a user system for a specific feature. These models share some common attributes but serve different use cases. Because of separate entities, creating validation rules on user attributes or authentication/authorization requires a significant amount of duplicated efforts.

My goal is to centralize account management avoiding duplicating development efforts. At the same time, I want to avoid the "new standard" problem.

Here are some approaches that I could think of.

1. Introduce a new parent-level data model or entity that can capture all these use cases, and migrate each system to use the new data model or entity.
2. Design minimum domain entity and use bounded context to support different use cases.
3. Introduce a new parent-level abstract data model with translation logic, creating links or associations between entities to the parent model.

At the same time, I think this is one of the common problem patterns that companies try to solve as the system grows. So I was wondering if there is a good software engineering practices that I can follow to centralize similar domain entities. Either by introducing a new entity, or merging and folding entities or with associations.

Answer 1

I understand that there are two different concerns:

• There is the concept of user, which can be registered (account) or not (anonymous).
• At the same time, users seem to have roles in the game (player, observer)

The users are temporarily associated to roles for the time of a game. This pleads in favour of association, i.e. composition over inheritance. At the same time you need to cope with the modern and the legacy version:

• In the new design, you could relate the two bounded contexts with the conformist pattern.
• In the legacy application you'd probably prefer to use the anti-corruption layer to relate the two worlds using adapters. Because you don't want to rewrite big parts of the old applications, do you?