How do you handle relationships between entities across different libraries? I am specifically hinting to the fact you might have multiple libraries, which you don’t necessarily use in all applications, so you might end up with including an entity with a relationship through it’s library, but not including the inverse entity of a relationship of the included entity
A versatile fullstack with leadership experience, with IT and non-IT background. NestJS / Vue / hybrid apps / graph databases afficionado. Versatilist always beyond the very IT bubble.
Well, not necessarily like that, at least to my mind. If a library has become a library, it means it has (or should have!) well-defined boundaries of its context. With a reusable UserModule we have a very strictly defined scope of what it does. Now, if we want to make users the owners of the cats, all it takes is to define the relationship in the CatEntity. First, because we don't need, at any cost, the inversion of relationship. Second, logically, UserModule should not cover any logic or scenarios involving users as the owners of the cats, because it's the app-specific domain.
So, in a hypothetical scenario where we would want to implement the logic for a user shelters a cat scenario, that scenario should probably be handled by neither UserModule, nor CatModule, but by a CatOwnerModule, with a service that first fetches the user, then fetches (or creates) the cat entity, assigns to the latter a relationship to the former, and persists the data. As such, the boundaries between contexts (user, cat, cat owner) are not leaking.
Actually, I'm rather inclined to think that if there's a matter of whether we need to define the relationship inversion on some another module, or not, it most likely means, we need another context.
Besides, the very structure of NestJS, broke down into modules, works pretty much similar to the modules as separate libraries. There's hardly any, if any at all, argument for extending in-app UserModule to handle the scenarios which are of another module's interest.
A versatile fullstack with leadership experience, with IT and non-IT background. NestJS / Vue / hybrid apps / graph databases afficionado. Versatilist always beyond the very IT bubble.
On a margin note, in real life, it's not being a person that makes us benefit from the cats we have, or gives us some responsibility. It's the abstract notion of the ownership of a cat. We are accompanied by our cats, because we own them, not because we have two legs, eyes, passport, and a birth certificate. The cats are not petted or fed because they have whiskers, and a specific painting. It's because of a relation between them, and a human feeder, let's say that's the ownership I'm mentioning. So the ownership is something aside from being a person, and aside from being a cat, and both people and cats can function without it, they won't lose their identity, they won't become unable to live, or to produce the ID upon police officer request ;)
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
How do you handle relationships between entities across different libraries? I am specifically hinting to the fact you might have multiple libraries, which you don’t necessarily use in all applications, so you might end up with including an entity with a relationship through it’s library, but not including the inverse entity of a relationship of the included entity
Well, not necessarily like that, at least to my mind. If a library has become a library, it means it has (or should have!) well-defined boundaries of its context. With a reusable
UserModulewe have a very strictly defined scope of what it does. Now, if we want to make users the owners of the cats, all it takes is to define the relationship in theCatEntity. First, because we don't need, at any cost, the inversion of relationship. Second, logically,UserModuleshould not cover any logic or scenarios involving users as the owners of the cats, because it's the app-specific domain.So, in a hypothetical scenario where we would want to implement the logic for a user shelters a cat scenario, that scenario should probably be handled by neither
UserModule, norCatModule, but by aCatOwnerModule, with a service that first fetches the user, then fetches (or creates) the cat entity, assigns to the latter a relationship to the former, and persists the data. As such, the boundaries between contexts (user, cat, cat owner) are not leaking.Actually, I'm rather inclined to think that if there's a matter of whether we need to define the relationship inversion on some another module, or not, it most likely means, we need another context.
Besides, the very structure of NestJS, broke down into modules, works pretty much similar to the modules as separate libraries. There's hardly any, if any at all, argument for extending in-app
UserModuleto handle the scenarios which are of another module's interest.On a margin note, in real life, it's not being a person that makes us benefit from the cats we have, or gives us some responsibility. It's the abstract notion of the ownership of a cat. We are accompanied by our cats, because we own them, not because we have two legs, eyes, passport, and a birth certificate. The cats are not petted or fed because they have whiskers, and a specific painting. It's because of a relation between them, and a human feeder, let's say that's the ownership I'm mentioning. So the ownership is something aside from being a person, and aside from being a cat, and both people and cats can function without it, they won't lose their identity, they won't become unable to live, or to produce the ID upon police officer request ;)