Разделение системы на модули?

Question

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

Во многих умных книжках пишут, что следует разбивать систему на более мелкие и простые части (подсистемы|пакеты).

Рассмотрим простой пример (возможно не самый лучший).
Допустим, нам нужно разработать API для сервиса по поиску фильмов (наподобие кинопоиска).
Предположим, мы решили, что нам нужно хранить следующую информацию:

Фильмы

• Название
  
• Описание
  
• Дата релиза
  
• Жанр[]
  
• Страна[]
  
• Люди[] (актеры/продюсеры и т.д.)
  
• Рейтинги[]
  

Жанры

• Название
  

Страны

• Название
  

Люди

• ФИО
  
• Пол
  
• Дата рождения
  
• Дата смерти (если умер)
  
• Биография
  

Рейтинги

• Стороняя система (IMDB, кинопоиск)
  
• Рейтинг
  

Я бы разделил систему с такими данными на следующие модули:
1. Фильмы (фильмы, жанры, страны) - основные данные о фильмах
2. Люди
3. Сторонние системы и рейтинги

В моем представлении, если модулю нужно работать с БД, он должен иметь свою собственную БД. Если же БД одна, то модуль должен знать только о пренадлежащих ему таблицах и ни в коем случае не должен обращаться к таблицам чужих модулей.
Возникает вопрос: предположим, нужно предоставить пользователям API возможность получения фильмов, в которых принимал участие какой-то человек.
Или нужно отсортировать фильмы по рейтингу IMDB. Модуль фильмов не должен знать ничего о модуле рейтинга. Как быть в этой ситуации?

Answer 1

[Евгений Шатунов]

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

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

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

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

Comments

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

Правильно ли я понимаю, что в моем случае утилитарной подсистемой является само приложение (API), которое знает о других модулях?

Для меня остается непонятным один момент: как правильно выполнять выборку, если нужно отсортировать данные из одной подсистемы используя данные другой + получить только те данные, которые соответствуют определенным данным из третьей подсистемы? У меня в голове возникает лишь одно решение: выполнить SELECT по данным основной подсистемы и программно осуществлять фильтрацию и сортировку. Но этот вариант, как мне кажется, ужасен, т.к. если у нас в БД много записей, мы каждый раз выгружаем их в память.

[Евгений Шатунов]

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

А вот на счет утилитарных подсистем можно сказать так. Это не важно, как именно подсистема выполняет свои функции. Если у тебя есть возможность сделать так, чтобы от фильмов получить один кусок, от актеров - другой, от рейтингов - третий, потом ничего о самих этих данных не зная собрать из них прямой SQL-запрос, то можно так и сделать.
Важно понимать только одно, структуру данных в хранилище знает только подсистема данных, она может помочь сформировать более специализированный запрос для драйвера хранилища.
Если же такой возможности нет, то функциональность надо вводить любым другим разумным и доступным способом.