SOLID здорової людини

Більшість інженерів, включаючи мене, відносяться скептично до строгого дотримання цих принципів. Але сучасна розробка - це майже завжди trade-off і якщо трохи підігнати їх під реальне життя, вийде доволі непоганий набір хороших практик.

Тому ловіть життєву версію SOLID:

S - Single Responsibility

Якщо ти назвав свій сервіс AuthService, то будь ласка не пхай туди логіку повʼязану з платежами, валідацією і так далі.

Принцип каже, що має бути тільки одна причина для зміни цього сервісу і це зміни в Auth Flow.

O - Open/Closed

Якщо тобі треба внести якісь зміни в сервіс чи компонент на 2000 рядків коду, і ввечері ти хочеш відпочивати, а не відкочувати свої зміни з проду, краще не чіпай те гівно, а додай свої зміни поверх цього атракціону.

Принцип каже, що компоненти системи мають бути закритими для змін, але відкритими для розширення.

L - Liskov Substitution

Якщо ти по пʼяні вирішив перевизначити стандартний метод у репозиторії якоїсь ORM, наприклад UserRepository.find(), то семантично цей метод усе ще має щось шукати. Не треба в ньому щось видаляти чи створювати нові записи.

Принцип каже, що дочірній клас має безпечно замінювати батьківський.

I - Interface Segregation

Якщо бачиш величезний інтерфейс чи тип і хочеш зробити вигляд бурхливої діяльності, можеш розбити його на кілька менших. Усім буде пох, але ти зробиш PR і матимеш що сказати на дейліку.

Принцип каже, що краще мати кілька малих інтерфейсів, ніж один великий: так їх простіше перевикористовувати.

D - Dependency Inversion

В ідеалі твоя архітектура має залежати від абстракцій, а не від реалізацій. У реальному житті базовий мінімум - це взяти нормальний Node.js фреймворк, де з коробки є Dependency Injection, наприклад NestJS.

Без цього доведеться ініціалізувати залежності всередині бізнес-логіки. А це розірве вам жопу, коли проєкт розростеться і треба буде вносити зміни або покривати код тестами.

Принцип каже, що високорівневі модулі не мають залежати від конкретних реалізацій. Тобто вашому API контролеру має бути все одно, який саме сервіс підставлять усередину. Головне, щоб він відповідав потрібній абстракції: інтерфейсу, класу або токену провайдера.