Проектирование систем и сервисов

Программирование это не только написание кода, но и проектирование архитектуры.

И как удобнее код будет разложен по папкам, зависит жизнь проекта.

Идеи как это можно сделать в этой заметке

Модульный монолит

Делим проект на модули в рамках одного проекта, где каждый модуль выполняет свою функциональную работу.

Например:

Blog - блог
Comment - комментарий
Favorite - избранное
Payment - оплата

Нужно придерживаться того, чтобы каждый модуль работал, только со своими данными. Система должна быть слабосвязанной.

Данные нужно размещать в те места, сервисы, которые работают с этими данными. Вместо того чтобы бросать все в один модуль нужно разграничить обязанности

Blog - блог только данные блога
Order - заказ, только данные заказа
Comment - комментарий , только комментарии

Модули снаружи слабосвязанные. Модули внутри должны быть сильно связаны.

Главное, чтобы внутри модуля были нужные данные. Нужно программировать систему так, чтобы было удобно менять код.

Будьте устойчивы к изменениям, чтобы не приходилось ходить за ними в другие места

Связи на другие классы

У каждой сущности должен быть свой user, а не общий для всего сайта.

Например, user у каждой сущности свой

• автор
• пациент
• заказчик
• клиент

Никакой модуль не должен использовать классы из других модулей

Модуль может использовать только id из других модулей. Общение должно идти по api модуля

Дублирование кода

Если классы похожи друг на друга - это не значит что это одинаковые классы.

Например, какой-нибудь расчет зарплаты нужно вынести в отдельный метод или сервис.

Выносим отдельно только одну и ту же логику, а не просто похожие классы.

Ориентируемся на здравый смысл. Объект адрес у всех разный. Проще для каждой сущности создать отдельный адрес

profile
    address
        country
        city
        home
delivery
    address
        country
        city
        home 
client
    address
        country
        city
        home          

Сложная агрегация данных

Если у нас сложная выборка и объединение данных, в этом случае пишем новый модуль, например

Report
Statistics

Нужно произвести экспорт из всех нужных сервисов и объединить их в отдельном модуле. Каждый сервис должен содержать только данные с которыми он работает, и ему должно быть все равно, что происходит вокруг него.

Данные из сторонних сервисов

Лучше вынести в отдельный сервис информацию из сторонних сервисов.

Например ФИО, выносим в отдельный сервис и подтягиваем уже оттуда.

Итог

Разделение на модули позволяет нам

• Делать сколь угодно большие проекты, за счет того что можем интегрировать сервисы друг с другом.
• Каждый модель независим от других, а это значит, что его можно разрабатывать и тестировать отдельно.
• Слабая связанность компонентов.

Содержание