Проблема більшості веб‑додатків — не технології, а хаос відповідальностей
Коли “все зі всім” пов’язано, будь‑яка зміна стає ризиком. Архітектура — це про межі: де живе бізнес‑логіка, як дані заходять у систему і як вона віддає їх назад.
1) Мисли модулями, а не сторінками
- Виділи домени: користувачі, ролі, замовлення, оплати, контент тощо.
- У кожного домену — свої контракти: DTO/типи, use cases, репозиторії.
- Заборони “прямі” імпорти з іншого домену без явного API.
2) Шари: UI → application → domain → infrastructure
Навіть якщо ви не робите “чисту архітектуру”, ідея шарів дисциплінує:
- UI не знає про БД і “сирі” клієнти API.
- Application шар оркеструє сценарій (use case) і валідацію.
- Domain містить правила (інваріанти) — те, що не можна порушувати.
3) Контракти між фронтом і беком
- Єдина модель помилок і статусів.
- Версіонування або “м’яка” сумісність (додавати поля можна, ламати — ні).
- Схеми/валідація (Zod/Joi) на вході — щоб не ловити “дивні” стани.
4) Правила для команди
- Code review по архітектурних межах (не тільки по стилю).
- Лінт‑правила/імпорт‑обмеження для доменів.
- Стабільні інтеграційні тести для критичних use cases.
Підсумок
Розвивати веб‑додаток легко, коли є межі модулів, зрозумілі контракти і шар, де живуть правила бізнесу. Тоді зміни стають локальними, а не “по всьому проекту”.