Небольшой пост о том, как я спроектировал свою первую систему | /maffinca

Небольшой пост о том, как я спроектировал свою первую систему на реальном коммерческом проекте. Т.к на основной канал пока нет идей, что написать - напишу, что делал пару дней назад
Как некоторые знают (а может и нет) - я backend разработчик. Недавно у нас стартовал новый проект и т.к наш тимлид ушел из компании, подготовку инфрастуктуры и проектирование архитектуры проекта доверили мне (задача пришла от директора по производству), но с условием, что перед передачей ее менеджеру нужно согласовать с тех.директором
Раньше я уже видел, как проектируют в нашей компании, начинал пару раз новый проект, поэтому примерно представлял как это делать
Сдела вот пару советов - как нужно делать архитектуру. Напомню, что проектировал я первый раз в жизни, поэтому советы будут весьма простые, как некоторым может показаться:
1. Если у какой-то сущности может быть привязка к нескольким данные другой таблицы - надо сделать еще одну.
Например: профиль человека может иметь несколько городов в себе - в таком случае простой внешний ключик не прокинуть, т.к значение не одно, поэтому следует сделать 3 таблицу: profiles_as_cities, которая будет иметь 2 внешних ключа на профиль и на город. В этом случае нельзя пихать ключ на профиль в городах, ибо это как минимум нарушение SRP, так и просто дубликаты в таблице, которая их по идее иметь не должна
2. Не нужно делать сложно. Чем проще и «тупее» выглядит схема, тем лучше. Не надо строить дикие связи между таблицами - это усложит разработку софта в будущем. Схема должна быть максимально простой.
Пример: на одном из проектов у нас были работники и работодатели, которые привязаны к таблице application, которая в свою очередь отдавала внешний ключ на lead. Подход в будущем вызвал множество проблем при встраивании нового функционала. Опять же - чем проще система, тем легче ее будет поддерживать в будущем. Никто не знает, что нужно будет клиенту через месяц
Пример 2. Простой пример - пользователи и роли. Пользователи в одной таблицы, роли в другой. А так ли это нужно? Вы уверены, что вам нужна таблица ролей? Если не планируется делать фильтрацию, выборку и т.д по ней, то в ней нет смысла, можно в таблицу пользователей засунуть role как константу
3. Тут скорее не совет, а просто ресурс, который я использовал для проектирования - db design. Все наглядно и довольно просто. Разобраться - пол часа времени