0

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.

2
  • Is the business separation for these components a thing of the past? i.e. are they all owned and maintained by a single, coherent team/entity with sole responsibility for all development? Or are these expected to be owned by separate autonomous teams with their own priorities? A key consideration for DDD is ensuring a domain model reflects the human structure of the business itself. Full consolidation may not be useful if autonomous teams still need to evolve in different directions -- if that's the case then a single model could harm the autonomy and lead toward "waterfall". Commented Oct 6, 2022 at 7:52
  • Do those concepts currently exist within different bounded contexts?
    – Rik D
    Commented Oct 7, 2022 at 17:47

1 Answer 1

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?

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.