Understanding Database Design

In a word, it's a group. For a single belonging group, for multiple belonging groups, or for hierarchical groups.
You may belong to more than one group and have a preferred group.
The right design is determined by what you expect.

Maybe the reason I'm hesitating now is not because of future scalability, but because the group's requirements have not yet been met.
If so, I think we should wait for the design until we make a decision.

They say, "You should design with a view to the future," and they say, "It's no use looking too far into the future."There is no correct answer.

In this situation, the designer's skills themselves can make better choices by judging various factors.

I'll think about it with a framework approach.

The one who wrote all over the place in user.group. If you use user.groups, it's hard because it's an array of record instances.
"In that case, it would be easier to say ""it's always an array, but only one case is coming back"" from the beginning."

However, even in that case, it is meaningless to write user.groups.first.

From the above
"Design on the assumption that there are multiple groups (=You can define behavior when there are multiple groups)"
It's based on whether or not.
If you can't define it at this time, rather than writing it. It would be less stressful to nudge, "In that case, there will be a change cost, right?" :)