If a schema can have several belongs_to associations with different other schemas then to which of these does it really belong?
For me, the belongs_to name implies the idea of aggregation between schemas, but an aggregate is something indivisible, so the fact that something can have several belongs_to associations does not seem to make sense.
An AGGREGATE is a cluster of associated objects that we treat as a unit for the purpose of data changes. Each AGGREGATE has a root and a boundary. The boundary defines what is inside the AGGREGATE. The root is a single, specific ENTITY contained in the AGGREGATE. The root is the only member of the AGGREGATE that outside objects are allowed to hold references to, although objects within the boundary may hold references to each other. ENTITIES other than the root have local identity, but that identity needs to be distinguishable only within the AGGREGATE, because no outside object can ever see it out of the context of the root ENTITY.
You can build aggregates on top of a single or multiple schemas.
For a single schema, you can use embedded schemas, so the aggregate comprises the single schema and its embedded schemas.
For the other case, you have a “root” schema, and several child schemas, all separated, but at application level you treat a “root” and its “children” as an aggregate.
By using the notion of aggregate, you can leverage a typical SQL database as if it was a document-oriented one, with the advantages of both, but without the inconvenience of the second (mainly its query limitations to the inner parts of aggregates in these databases).
Essentially this results in building a document-oriented like database on top of an SQL database.
It’s been a long time since I read DDD, but if you squint you can correlate Phoenix contexts with a less strict type of bounded context.
The basic idea is that Ecto Repos do not have to map 1:1 with physical databases. You can set up an Ecto Repo per aggregate/context if you want. I have done this once with the idea that we might want to shift the database tables backing a particular aggregate to another physical database in the future. With this Repo separation, it would only involve Repo config change but no real code change. It offers a finer grain to the Repository pattern than most users of Ecto consider.
It’s been around for a long time but personally I always preferred the simple “one to many”, “many to one”, “many to many” and “one to one”.
Rails was very big on language expression when it first came out and there are entire rule sets around pluralization of object names, pluralizer libraries that account for language exceptions, etc to work within that model.
It is easier to say “A User belongs to an Account” than “Users are many to one with Accounts”. The inverse is fine “An Account has many Users”.
The issue was around key placement. If you say “A User has one Account” the language is fine but you don’t know where the key is stored. Rails went with “A User belongs to an Account” to mean the user table has an account id and “A User has one Account” to mean the Account table has a User id.
I think you have answered well to my original question, making clear what was the idea of introducing the belongs_to name. This name solved the problem you mention, nevertheless it causes confusion when thinking on aggregation between entities.
I don’t know if the idea of aggregates existed by the time Rails was introduced, if it existed but Rails’ authors were not aware of it, or if they were aware but ignored that choosing belongs_to would conflict with such idea. Perhaps they thought about it but did not find anything better than belongs_to that would solve the key placement problem, without conflicting with the aggregate idea.
Perhaps a better nomenclature exists …, perhaps it exists not.