Я был адептом чистой архитектуры

17 окт. 2025 г., 20:55👁 376↗ 5💬 8

5 лет назад, начитавшись кучу книжек и статей про чистую архитектуру, изучив огромное количество паттернов проектирования, я понял, что вот она - идеальная архитектура. Гексагональная архитектура с портами и адаптерами. Соблюдаем все принципы дяди Боба, отделяем базу данных от бизнес-логики, применяем Domain Driven Design. Сначала пишем на нативном "TypeScript" всю бизнес-логику с сущностями в виде классов с геттерами и сеттерами. Пишем use-cases, применяя принципы SOLID, в особенности Dependency Inversion - вместо реализации в use-cases пишем interfaces с методами. Но чтобы добавить простую фичу, приходилось: - Создать entity - Создать interface для repository - Создать реализацию repository - Создать use-case - Создать DTO для входа - Создать DTO для выхода - Создать mapper из entity в DTO - Создать controller - Создать interface для adapter - Создать реализацию adapter Чтобы добавить поле в форму регистрации, я правил 8 файлов. Что пошло не так: 1. Абстракции ради абстракций У меня было 50 интерфейсов с одной реализацией. Зачем? "Чтобы можно было заменить". Но за 3 года я не заменил ни одного. 2. Бойлерплейт Половина кода - маппинг между слоями. Entity > DTO > Response. И обратно. Это не бизнес-логика. Это просто перекладывание полей. 3. TypeScript - это не Java Я пытался писать на TypeScript как на Java. Классы, приватные поля, геттеры, сеттеры. Но TypeScript - это JavaScript с типами. Функциональный подход тут работает лучше. 4. Команде сложно Новый разработчик тратил недели на то, чтобы разобраться в структуре. Где что лежит? Зачем столько папок? Почему для одной фичи 12 файлов? Джун вообще не мог писать код, так как слишком много абстракций. Что я понял: Чистая архитектура работает, когда: - Большая команда - Сложная domain-логика (банк, ERP) - Долгоживущий проект (5+ лет)

В стартапе с командой 3-5 человек это оверкилл.

Сейчас я чаще всего использую какой-либо фреймворк типа NestJS если на NodeJS. Пишу проще. Без лишних слоев. А если понадобится сложность - добавлю. Пока работает просто.

Чистая архитектура - не плохая. Но не для всех проектов.

15/100 Telegram

211

Комментарии · 8

@shaurgon18 окт. 2025 г., 04:49
Ух, как я тебя материл, когда приходилось в это лезть 😂
- @gavrilovlog18 окт. 2025 г., 06:14
  Наслышан 😁
@meafrank18 окт. 2025 г., 06:12
Что делать если проект без фреймворка? Необязательно же всегда усложнять интерфейсами и подобными абстракциями, не?
- @gavrilovlog18 окт. 2025 г., 06:14
  Вообще необязательно
  - @meafrank18 окт. 2025 г., 06:16
    Это понятно, а что ты делаешь когда в проекте нет фрейма?) Если условно проект для стартапа 3-5 и менее человек, но чтобы через год фичи добавлялись без крови и пота
    - @gavrilovlog18 окт. 2025 г., 06:32
      Если с нуля делать и чтобы без крови и пота, то лучше фреймворк использовать. Это проще и онбординг легче. Если не использовать фреймворк, то проще в функциональном стиле всё писать, меньше абстракций использовать. Если есть какая-то разветвленная логика, например сервис биллинга, где в зависимости от выбранной валюты оплаты, нужно выдавать определенный провайдер, то можно сделать через фабрику это. Тогда тут абстракция подойдет в виде интерфейса с методами: создать платеж, узнать комиссию и тд.
@raqetaa18 окт. 2025 г., 20:19
Ох, мне вот нужно замерить БД и как бы я был сейчас рад чистой архитектуре на которую я в этом месте положил. Когда понадобится будет уже поздно :) 5й день переписываю-причесываю. И конца края нет
@raqetaa18 окт. 2025 г., 20:21
Но в целом в начале так и нужно. Ложить на архитектуру, а то так вообще ничего не сделаешь

← вернуться к постам открыть в telegram →▶ play_post