Oi Rafael!

Uma coisa que podemos fazer pra considerar qual o lado mais forte é pensar se faz sentido ou não um objeto existir sem o outro.

Por exemplo, se pegarmos um cenários onde temos Conta e Movimentacao. Seria muito conveniente que a Conta tivesse uma lista de Movimentacao. Assim poderíamos facilmente fazer algo como:

minhaConta.getMovimentacoes();

Mas se pensarmos do lado da Movimentacao, toda Movimentacao deveria estar associada com uma Conta. Pro negócio talvez não faça sentido ter uma Movimentacao sem Conta. Então esse vira o lado forte:

public class Movimentacao {
    // outro atributos

    @ManyToOne
    private Conta conta;
}

Porém se já mapeamos deste lado, não deveríamos mais ter a lista de movimentações na conta... é aí que entra o mappedBy, uma forma de informar pro Hibernate que já fizemos o mapeamento do outro lado, e que ele não deve mais se preocupar em gerenciar os objetos dessa lista (como gerar o relacionamento no banco), já que ele já irá criar o relacionamento baseado no @ManyToOne da classe Movimentacao:

public class Conta {
    // outros atributos

    @OneToMany(mappedBy = "conta")
    private List<Movimentacao> movimentacoes = new ArrayList<>();
}

Dessa forma alista fica só como uma conveniência pro nosso lado da orientação a objetos. :)

Faz sentido? Abraço!

Acredito que entendi. No caso, o que vai determinar a "força" é a dependência da entidade para com a relação, certo? De toda forma, muito obrigado pela explicação.

Oi Rafel, isso mesmo! Juntamente com o que será gerado no banco.

No caso da Movimentacao ter a Conta, faz com que no banco a tabela de movimentacao tenha uma coluna conta_id, que é uma chave estrangeira pra um registro da tabela conta. Isso é o que seria esperado normalmente.

Abraço!