Виталий Катомин

Стоит добавить еще один айди, чтобы при всяких редактированиях сущности Личности фильма тягать по этому айди данные из бд, и потом их туда же толкать по этому айди (то есть не будет возни со сменой данных, которые уже являются составным первичным ключом).

Ты все правильно думаешь. Базовое разделение на модули выглядит рационально.
А дальше давай думать логически.

Мы хотим из одной подсистемы взять что-то, а данные другой подсистемы использовать как признак выборки. Наш новый механизм сам собой выглядит как часть полностью отдельной от первых двух подсистемы. Он должен находиться в третьей подсистеме, сущности которой будут знать все нужное как о первой, так и о второй подсистемах.

В итоге, нам надо завести утилитарную подсистему, связанную как с фильмами, так и с рейтингами.
Для утилитарной подсистемы нормально знать сразу о многих других подсистемах, даже о других утилитарных. Поэтому в одной утилитарной подсистеме можно завести связи между фильмами и актерами, фильмами и внешними рейтингами, и.т.д.
Чувство меры в этом деле работает на уровне богатства интерфейса по связи между подсистемами. Если связь между некоторым набором подсистем порождает богатый интерфейс, то этот интерфейс имеет смысл выдавить в отдельную подсистему.

Более того, я обычно рекомендую полностью разделять данные и логику в разные подсистемы. Всякие там поиски, фильтрации и прочие любые манипуляции над неизменными данными лучше держать в отдельной подсистеме. Тогда всегда будет понятно, структура данных поменялась или метода манипуляции с этими данными.