Então mestre,
Relacionar por identidade ao invés de referência funciona, mas meio que quebra a modelagem objeto-relacional, porém de acordo com essa regra temos alguns benefícios.
Eu vi sobre essa tal regra no livro domain driven design distilled:
Rule 3: Reference Other Aggregates by Identity Only
Now that we’ve broken up the large-cluster Product into four smaller Aggregates , how should
each reference the others where needed? Here we follow Rule 3, “Reference other Aggregates by
identity only.” In this example we see that BacklogItem , Release , and Sprint all reference
Product by holding a ProductId . This helps keep Aggregates small and prevents reaching out
to modify multiple Aggregates in the same transaction.
This further helps keep the Aggregate design small and efficient, making for lower memory
requirements and quicker loading from a persistence store. It also helps enforce the rule not to modify
other Aggregate instances within the same transaction. With only identities of other Aggregates ,
there is no easy way to obtain a direct object reference to them.
Another benefit to using reference by identity only is that your Aggregates can be easily stored in
just about any kind of persistence mechanism, such as relational database, document database, keyvalue store, and data grids/fabrics. This means that you have options to use a MySQL relational table, a JSON-based store such as PostgreSQL or MongoDB, GemFire/Geode, Coherence, and GigaSpaces
Um pouco dificil copiar o que tem no livro e a pessoa não pega o contexto também, mas digitando o nome da regra no google tem várias coisas.
Nesse link : https://vaadin.com/learn/tutorials/ddd/tactical_domain_driven_design na sessão Guideline 2: Refer to other aggregates by ID
tem essa regra resumidamente explicada também.
Existe a enorme possibilidade de eu estar fazendo confusão também, hoje terei tempo para voltar a praticar um pouco sobre o que tenho lido, e na prática a gente desfaz algumas confusões ou cria a certeza que tal coisa é um problema.
