Гексагональная архитектура для Node.js-приложения, или Как сделать код более поддерживаемым

Привет, меня зовут Андрей, я Engineering Manager в компании Uptech. В этой статье хочу рассказать об одном из архитектурных подходов для создания приложений — гексагональной архитектуре. Рассмотрим пример ее использования для создания Node.js-приложения.

Если ищете способ улучшить поддерживаемость и тестируемость кода, тогда эта статья для вас.

TLDR. Разделяйте бизнес-логику и любые внешние зависимости — будьте счастливы.

Перед тем как начать, давайте разберемся, какие проблемы нужно решить. Основное — сделать код более поддерживаемым. А именно: быстро добавлять новые фичи, легко менять одни зависимости на другие и тестировать код. Фактически минимизировать технический долг в долгосрочной перспективе. Гексагональная архитектура при правильном использовании может удовлетворить наши желания.

Рассмотрим типичное приложение:

В более общем случае:

Вроде все хорошо, но что обычно происходит в реальной жизни?

В разных доменных частях бизнес-логики появляется все больше и больше зависимостей. Сама бизнес-логика вызывает части инфраструктуры (например, запросы в базу данных или вызов сторонних сервисов) напрямую в разных частях приложения.

В итоге получаем жесткую зависимость между бизнес-логикой и инфраструктурой. В результате тестирование становится достаточно сложным и болезненным для разработчика.

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

Порты и адаптеры

Если посмотрим на описанный выше флоу, увидим, что роуты — это просто точки «входа» к бизнес-логике, а база данных и другие сторонние сервисы — «выходы» из приложения. И таких точек «входа» и «выхода» может быть много. Заметив это, Алистер Коберн в 2005 году предложил подход к архитектуре приложений, который назвал «гексагональная архитектура», или «архитектура портов и адаптеров».

В ее основе лежит идея изолирования бизнес-логики от любых внешних зависимостей с помощью концепта так называемых портов и адаптеров. Давайте разберемся, что они из себя представляют.

Наша основная цель — это изоляция бизнес-логики. Но нужен способ взаимодействия с ней. Порт служит именно для этой цели. Порт — описанная спецификация взаимодействия уровня логики с любыми внешними зависимостями. Это просто интерфейс, по которому бизнес-логика вызывается или сама вызывает внешние зависимости, без каких-либо деталей имплементации. Для большинства языков порт — это интерфейс и DTO (Data transfer object), связанные с этими интерфейсами. Порты принадлежат уровню бизнес-логики.

После того как описали процесс взаимодействия с бизнес-логикой, стоит раскрыть логику взаимодействия с конкретными сторонними сервисами и соединить их вместе. Для этой цели служат адаптеры. Адаптер — конкретная имплементация работы с другими сервисами. Эти сервисы бывают двух типов по отношению к «ядру» приложения. Те, которые логику вызывают — HTTP-роуты, Socket-соединения. Их называют первичными (Primary) адаптерами. И те, которых бизнес-логика сама вызывает: база данных, платежные программы, сервисы уведомлений и так далее. Их называют вторичными (Secondary) адаптерами.

Основная разница между ними в том, как они взаимодействуют с уровнем бизнес-логики. Primary-адаптеры втягивают в себя уровень логики и вызывают его напрямую. Они фактически говорят нашему приложению, что делать. А Secondary-адаптеры имплементируют порт и после этого инжектятся в уровень логики с помощью Dependency injection.

Выглядит это приблизительно так:

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

Первичный адаптер. HTTP endpoint

Наш календарь имеет обычный REST API и взаимодействует с внешним миром через HTTP. HTTP endpoint — самый простой пример первичного адаптера. Контроллер, который работает с вашим фреймворком и обрабатывает HTTP-запросы.

В данном случае метод CreateEvent обрабатывает POST-запросы по роуту /event, парсит все параметры запроса и вызывает eventCreationService, который есть частью слоя с бизнес-логикой. Он принимает на вход только значения и ничего не знает об особенностях транспорта, что его вызвал, таких как тело запроса или заголовки.

Таким образом мы убираем зависимость бизнес-логики от транспортного протокола и фреймворка:

@injectable()
@JsonController('/event')
export class EventController {
    // ...
    @Post()
    public async createEvent(
        @Body() input: EventCreationInput,
        @CurrentUser({required: true}) userId: number
    ): Promise<EventResponse> {
        return await this.eventCreationService.createEvent(input, userId);
    }
    // ...
}

Порт. Сервис нотификаций

Наш календарь отсылает уведомления и напоминания, и для этого слою бизнес-логики нужно уметь отправлять нотификации с помощью стороннего сервиса. Чтобы не зависеть от конкретного провайдера нотификаций, спрячем его за порт.

Порт в нашем случае — интерфейс, в котором описываем, как отправить нотификации. Для слоя бизнес-логики достаточно знать, что для их отправки нужно вызвать метод sendNotifications с конкретным сообщением и списком пользовательских токенов. Как именно это происходит на этом уровне, нам неважно.

Порт принадлежит сервису и используется на уровне бизнес-логики. В сервисе следует заинжектить конкретную имплементацию интерфейса. Это рассмотрим ниже.

export interface NotificationService {
    sendNotifications(message: NotificationMessage, userTokens: string[]): Promise<void>;
}

Вторичный адаптер. Сервис нотификаций

Теперь осталось описать, как именно оправлять нотификации с помощью конкретного провайдера. Для этого пишем вторичный адаптер. Он имплементирует описанный выше интерфейс NotificationService. В нем с использованием Firebase SDK имплементируем отправку нотификаций через конкретный сервис. Таким образом мы изолируем зависимость на Firebase SDK в одном месте нашего приложения. Адаптер нужно зарегистрировать в DI-контексте, чтобы потом заинжектить его в сервисе с бизнес-логикой.

@injectable()
export class FCMNotificationAdapter implements NotificationService {
    private readonly fcmApp: admin.app.App;

    constructor() {
        this.fcmApp = admin.initializeApp({
            credential: config.firebase.authJson
        });
    }

    public async sendNotifications(message: MessageData, tokens: string[]): Promise<void> {
        const payload = {
            tokens,
            notification: message.notification,
            data: {
                data: JSON.stringify(message.data)
            }
        };

        const response = await this.fcmApp.messaging().sendMulticast(payload);
    }
}

Inversion of Control

Обратите внимание: чтобы сделать вторичные адаптеры независимыми от бизнес-логики, используем Dependency injection (DI). Получается, что зависимости направлены к Application core. Работает принцип Inversion of Control сразу на уровне архитектуры.

Организация Application core

На этом этапе классическая гексагональная архитектура, описанная Алистером Коберном, заканчивается. А у нас большая часть приложения остается не организованной. Собственно, это «гексагон» с бизнес-логикой — Application core. Я поделюсь нашим подходом, как мы это делали. Для нас это неплохо сработало. Но фактически организация кора не является стандартизированной, поэтому эта часть полностью на ваше усмотрение.

Для организации бизнес-логики мы объединили подход слоевой архитектуры (Layered Architecture) и DDD (Domain Driven Design).

Вот что из этого вышло. Следуя слоевому подходу, мы разделили Application core на два слоя: Application и Domain. Domain отвечает за бизнес-логику, в нем хранятся доменные модели и сервисы, которые отражают бизнес-процессы. Это базовый слой, он не зависит от других частей приложения.

Слой Application связывает доменную логику с внешними сервисами. Application-уровень описывает полноценные пользовательские сценарии (use case). Здесь живут порты, через которые происходит взаимодействие с адаптерами. Запросы в базу и на другие сторонние сервисы вызываются из этого уровня.

Сервис Аpplication-уровня работает приблизительно так: он инжектит в себя вторичные адаптеры, не зная ничего о конкретной имплементации этих сервисов. В данном примере EventRepository и NotificationService — это порты, описанные на доменном уровне, для которых из DI-контекста инжектится конкретная имплементация взаимодействия с внешними сервисами.

@injectable()
export class EventCreationService {
    private eventRepo: EventRepository;
    private notificationService: NotificationService;

    constructor(
        @inject(EventRepositoryType) eventRepo: EventRepository,
        @inject(NotificationServiceType) notificationService: NotificationService,
    ) {
        this.eventRepo = eventRepo;
        this.notificationService = notificationService;
    }

    public async createEvent(input: EventCreationInput, userId: number): Promise<EventResponse> {
        const newEvent = Event.fromObject({
            ...input,
            creatorId: userId
        });

        const savedEvent = await this.eventRepo.save(newEvent);
        
        const message = {
            title: `You invited to ${event.title}`,
            body: 'Wanna participate?',
            data: {eventId: event.id}
        };

        await this.notificationService.sendNotifications(message, tokens);

        return savedEvent;
    }
}

Второй шаг организации Application core — это разделение на компоненты по доменной области. В каждом из них лежат сервисы и модели, которые тесно связаны между собой, но слабо зависимы от других частей приложения. Такой себе Bounding Сontext из DDD. Примеры таких компонентов: User, Reminder, Event и так далее.

В итоге получаем такую схему:

Для уменьшения связности между компонентами можно использовать event-driven подход и реализовать их взаимодействие на основании ивентов.

В результате мы получаем архитектуру, которая позволяет иметь маленькую связность между компонентами и не зависеть на внешние сервисы. Теперь посмотрим, как это тестировать.

Тесты

У нас было 3 вида тестов, каждый отвечал за свою часть архитектуры.

Unit-тесты

Классические unit-тесты для каждого сервиса. С их помощью мы протестировали бизнес-логику в Аpplication core. Они достаточно легковесны и быстро исполняются.

Integration-тесты

Также хотим понимать, что интеграции с внешними сервисами работают хорошо. Для этого не нужно тестировать какие-то огромные куски функционала, достаточно протестировать адаптеры. Сами по себе тесты медленные и тяжелые, поскольку выполняют запросы по сети и иногда требуют поднятия тестовой инфраструктуры. Но так как в адаптерах нет бизнес-логики и они небольшие, здесь не нужно много тестов.

Acceptance-тесты

Когда мы проверили бизнес-логику и интеграции с внешними сервисами, осталось убедиться, как система работает целиком. В этом помогут Acceptance-тесты. Они тестируют полный пользовательский сценарий, но с замокаными вторичными адаптерами. При этом выполняются быстро, так как не взаимодействуют с сетью. Из минусов — тесты могут быть очень большими для сложных сценариев, поэтому их написание и поддержка потребует много усилий. Чтобы сбалансировать усилия и пользу, мы выработали правило: один Acceptance-тест для одного пользовательского сценария и только для основного успешного кейса.

Звучит это все хорошо, а в чем подвох, спросите вы?

Проблемы

Гексагональная архитектура — не серебряная пуля и к тому же имеет ряд проблем, с которыми придется разбираться.

Транзакции

Транзакция — это абстракция уровня базы данных, которая используется на уровне бизнес-логики. Поэтому получаем прямую зависимость на базу данных на уровне Аpplication. А это то, чего хотелось бы избежать. Не все базы данных поддерживают транзакции, поэтому абстрагировать их не выйдет. Транзакции иногда могут требовать сложной логики роллбеков.

Оптимизация

Порой требуется вытащить данные из базы нетривиальным образом. Для этого пишем сложный запрос, описывая бизнес-правила, какие именно данныенужны. В итоге получаем «утечку» логики в адаптер, усложняем адаптер и тем самым лишаем себя части пользы от архитектуры. Приходится искать баланс между хорошей архитектурой и оптимизациями.

Валидация

Не очевидно, где именно должны быть валидации? С одной стороны, валидация — это часть бизнес-логики и должна жить в Аpplication core. С другой стороны, слои должны быть максимально независимы со своей валидацией на каждом уровне. Или достаточно проверить так где они приходят — на первичных адаптерах? Тут нет правильного ответа, выбирайте то, что больше подойдет вашему приложению.

Выводы

  • Отделяйте внешние зависимости от бизнес-логики.
  • Тестируйте код с разных сторон и не забывайте о здравом смысле.
  • В каждом подходе есть свои проблемы, будьте готовы их решать.
  • Помните, что не существует одного метода, который решит все проблемы. Оцените, насколько данный подход эффективен именно для вашей задачи. Например, если у вас мало бизнес-логики, наверное, гексагональная архитектура это не лучший выбор.

Полноценный демопроект можете найти на GitHub.

LinkedIn

55 комментариев

Подписаться на комментарииОтписаться от комментариев Комментарии могут оставлять только пользователи с подтвержденными аккаунтами.

Статья хорошая, как вводная часть в архитектуру «Порты и адаптеры». Было бы неплохо описать, почему ее называют еще «Гексагональной». Более детально и, может быть, формально раскрыть проблемы, которые она решает (организация исходного кода). Привести аналоги. Описать хотя бы ее преимущества.

З.Ы. побольше бы подобных статей на ДОУ.

один вопрос: почему архитектура гексагональная, если на картинке 8 сегментов?

Другое название архитектуры — «Порты и адаптеры». Цель названия «Гексагональная» — показать несколько различных интерфейсов (портов) во внешний мир — en.m.wikipedia.org/...​l_architecture_(software

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

Один существенный недостаток созданных такими людьми подходов в том, что они выдумывались для их конкретных целей, и (возможно) до опреденных пределов хороши в решении задач схожих с целями тех кто их изобретал, при условии того, что «культурный контекст» применяющих эту методологию близок к тому, что есть у изобретателя этой методологии

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

Есть ли что — то что может претендовать на выше перечисленное в более широких областях — есть. Что именно и каким образом, это большой отдельный разговор на килобайты текста.

Есть ли что — то что может претендовать на выше перечисленное в более широких областях — есть. Что именно и каким образом, это большой отдельный разговор на килобайты текста.

зачем разговор?
дайте просто 5 линков на это «есть»

вот например дайджест есть
The Software Architecture Chronicles
herbertograca.com/...​-architecture-chronicles

там есть линк на то вы имеете ввиду?
«Добавьте» его :)

softwarefoundations.cis.upenn.edu вот один, остальные надо приводить?

вот один, остальные надо приводить?

конечно. они же у вас под рукой, почему сразу не привели?

тем более что по названию глав — там ничего об архитектуре.

там ничего об архитектуре.

 я же говорю — на много килобайт. тлдр — архитектуру использаут для того чтобы, в частности: 1) понимать что делает код малыми услиями 2) тратить меньше усилий на напсание кода 3) чтобы этот же код было проще менять 4) проще отслеживать места поломок при изменениях. Там все эти вещи обеспечиваются немного другим образом, по этому не удивительно что

там ничего об архитектуре.
я же говорю

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

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

Там все эти вещи обеспечиваются немного другим образом, по этому не удивительно что

что они не имеют отношения к архитектуре, и поэтому естественный вывод
там ничего об архитектуре.

названные вами пункты — это далеко не полный список того что призвана решить архитектура.

зачем разговоры?
дайте 5 ссылок на новый подход к архитектруре в ПО, и все.

дайте 5 ссылок на новый подход к архитектруре в ПО, и все.

товарищ, ты просишь меня дать тебе нечто в форме, в которой оно непредставимо. С такими запросами не ко мне. Это выходит за рамки понятий в которых сидят дэдэдэ гексагоны и прочие придумки.

в которой оно непредставимо.

именно потому что оно не имеет отношения к архитектуре, поэтому и — непредставимо :)

С такими запросами не ко мне.

ну вы же написали что знаете Великий Универсальный Подход.

Это выходит за рамки понятий

да, Бога познать нельзя.

прочие придумки.

даже 5ти ссылок невозможно предоставить о других придумках.
Великий Универсальный Подход оказывается еще и Великая Тайна.

это понятно, спасибо.

«Если гора не идёт к магомеду, тогда магомед идёт к горе», нет магомед сидит на месте и говорит что гора — неприступная.

Бремя доказательства лежит на утверждающем.
Вы сказали что у вас «есть» нечто.
но показать это нечто — нельзя. сформулировать — тоже.
Значит это нечто «Бог», или что-то из этого ряда. Есть такие вещи, которые невыразимы словом, или в позитивных определениях. Но мы то не теологическом форуме, верно?
хотя ладно, давайте тогда попробуйте выразить апофатически.

А причина неуловимости Джо нередко оказывается в том что он нафик никому не нужен.
В вашем случае даже вам, который не смог найти
5ти ссылок во всем огромном интернете.

и ожидает что сейчас как ломанутся другие, разгадывать Великую Тайну?

но показать это нечто — нельзя. сформулировать — тоже.

 в форме 5 ссылок так чтобы ты понял, мил человек, нельзя. Надо писать 30 страниц которые ты читать не станешь. Я ожидаю что люди почитают хоть немнго теории уже разработаной перед тем как валякать свою как попало.

в форме 5 ссылок так чтобы ты понял, мил человек,

мы не в привате.

дайте 5 ссылок — всем.

Я ожидаю что люди почитают

так дайте ссылки.

зачем читать теорию не имеющую отношения к архитектуре ПО?
дайте ссылки, где будет показано что имеет, и вот, вот и вот — решила проблемы конкретного проекта.

автор статьи вот потрудился рассказать.

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

что это — невыразимо...

тем как валякать свою как попало

расскажете о своем проекте, какую архитектуру применяли, и делов то.

я ж уже пытался у вас выяснить, что за тайну вы прячете от общественности :)

но воз и ныне там, ни ссылок, ни рассказа, а только
я знаю секрет — но никому его не понять, поэтому я никому его не скажу.

где будет показано что имеет, и вот, вот и вот — решила проблемы конкретного проекта.

 в этих ссылках этого не написано. Как это применять к решению конкретных задач — нужно думать самому. Почему и как это лучше — нужно разводить писанину на каждый нанопоинт по дофига страниц, иначе просто никто ничего не поймёт.

в этих ссылках этого не написано

да, я как бы в курсе, что там и не могло быть этого написано ;)
и не будет там никогда этого написано, потому что авторы — не занимаются разработкой ПО. они ж не инженеры :) и даже не консультанты, коучи.
они те о которых Дейкстра говорил
«что может знать астроном об изготовлении телескопов?»

понимаете?
пилот Боинга может быть очень крут. образован, с высокой ЗП.
но он не может наставить рыбака с Конго — как тому лучше рыбу ловить. он же ее не ловит, откуда ему знать :)
даже авиамеханику он мало что может посоветовать.

нужно думать самому

то есть читать смысла нет :)

Почему и как это лучше — нужно разводить писанину на каждый нанопоинт по дофига страниц

которую да, поэтому читать мало кто будет. потому что потом все равно — надо думать самому.
а показать результат в виде 5ти ссылок как морковку — тоже невозможно.

иначе просто никто ничего не поймёт.

как и гоняться за неуловимым Джо.

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

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

так оно бывает, с тем что — толковое, но очень новое. находятся те кто рискует — и побеждает. чаще конечно оно, как все в науке, оказывается пшиком, непотвержденной гипотезой, которая ах, как была прекрасна!

ждем ваших применений :)
ну или кого-то другого.

Код теперь практически не отличим от Java + Spring, хахахахаха

С таким же успехом можно сказать, что код не отличается от .net+C#+ASP.NET MVC или <подставь_свой_язык_и_либы/фреймворки>. Архитектура — это не о языке и не о либ/фреймворках.

Подозреваю, что существует своеобразная «секта» NodeJS разработчиков, которая искренне считает, что «не надо нам тут в ноде этой вашей архитектуры с паттернами и фабриками»

Да, и они очень любят шутить про абстрактные фабрики декораторов в джаве))

прочитал. имхо много наукообразных терминов, которые до конца понимает только 5% разработчиков. все эти порты-адаптеры-домены-транзакции.
имхо лучше объяснить принципы
— DependencyInjection (Inversion of Control)
— интерфейсы
— low coupling
— структурирование проекта по папочкам с понятными названиями

и иметь какой-то модный линтер который будет ругаться на опеределенные конструкции (ну например нельзя инстанцировать какие-то объекты в файлах каких-то папок)

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

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

прочитал. имхо много наукообразных терминов, которые до конца понимает только 5% разработчиков. все эти порты-адаптеры-домены-транзакции.

Да, печалька в сообществе js-бэкенд разработчиков Украины. Там всего 5% мидлов и синьоров, все оставшиеся 95% — джуны. Вам не позавидуешь :(

да, и 50% думает что они мидлы и синьоры, вставляют в разговор умные слова, не до конца понимая их смыл, пользу которую несут обозначаемые концепции, их слабые стороны, когда их стоит применять, а когда нет.

имхо лучше объяснить принципы

Не поверите, но на DOU писать статьи может каждый ;)

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

Потому что джунам в самом, самом начале надо рассказывать про YAGNI.

Почти половина проблем в ИТ — из-за оверинжиниринга ;)

Потом про DRY. И что в случае конфликта между YAGNI и DRY приносить в жертву DRY.
И только потом все остальное.

я сча менторю пачку студиков-джунов и понимаю что дай им ваши объяснения

Ну то не давайте ;)

В автошколе ж не учат полицейскому развороту, а сначала расположение педалей, правильному хвату руля и т.д.

Проблемы, которые здесь затронуты — не для джунов.

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

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

неплохая базисная статья.

Звучит это все хорошо, а в чем подвох, спросите вы?

как всегда и везде
подвох в том что абстракции протекут. обязательно.

Протечки частично уже назвали
Транзакции, Оптимизация, Валидация

И после всего что придется написать, с трудом будет узнать
«подход слоевой архитектуры (Layered Architecture) и DDD (Domain Driven Design)»

и новые программисты глядя на решения в проекте будут ныть — какое лэгаси, какая дебильная архитектура, «вернее ее отсутствие!»
почему не использовали гексагональную? про DDD не слышали?? ну хотя бы как-то слоили, рукожопы!

Подвох в том что все красивые схемы, названия архитектур точно так же как «паттерны ООП», сами по себе ничего не решают.
Потому что они не учитывают нюансы функционала проекта. Утрировано — они обо всем и «ни ап чем»

Они — карта.
Но:
Карта может обладать структурой, схожей или несхожей со структурой территории.
Карта не есть территория.
(Альфред Коржибски)

Примерно тот же в подвох в управлении проектами, в выборе методологии и метрик управления.
Какие красивые графики, роадмапы. Скоупы вот у нас, ...

Вобщем как в любой теории — подвохи все на практике :)

А статья о карте хорошая. Базовые вещи :)

Звучит это все хорошо, а в чем подвох, спросите вы?

как всегда и везде
подвох в том что абстракции протекут. обязательно.

Конечно протекут, особенно если проект отдать на аутсорс. Но в чем причины? А основная причина в том, что

Примерно тот же в подвох в управлении проектами, в выборе методологии и метрик управления.

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

и новые программисты глядя на решения в проекте будут ныть — какое лэгаси, какая дебильная архитектура, «вернее ее отсутствие!»

Так и будет на проекте, на котором вообще не выделяется время на архитектурный анализ, документирование, и поддержку документации в актуальном состоянии.

Протечки частично уже назвали
Транзакции, Оптимизация, Валидация

Смотря какие транзакции — системные или бизнес транзакции? Системную транзакцию не составит особого труда абстрагировать от реализации. И если новая БД не поддерживает транзакцию, то не беда, все будет работать. А вот для бизнес транзакций есть ряд готовых решений, например, паттерн Saga. И если вы особо не заморачиваетесь на выделение абстракции бизнес транзакции в вашей системе, то тут особо не надо удивляться течи вашей системы в будущем.

Оптимизация ни как не влияет на предложенную архитектуру. Например, у вас есть относительно большой корневой агрегат c немалым количеством связанных сущностей. Вам необходимо делать различные выборки частей данных этого агрегата. Можно смело применить паттерн CQRS, который решит проблему оптимизации выборки данных.

С валидацией вообще не понятно, в чем проблема. Если автор не совсем разобрался в этой теме, то это не значит, что предложенная архитектура течет :)

З.Ы. течь будет любое «плавучее средство», если его проектировать с дырками в дне :)

Абстракции протекают потому что им положено протекать. В силу ограничений метода — абстрагирование.

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

это в каких сказках выделяется достаточное время на это?
в тех где абстракции не протекают, «если их правильно готовить»? ;)

Смотря какие транзакции — системные или бизнес транзакции?

и те и другие.

абстракции бизнес транзакции в вашей системе, то тут особо не надо удивляться течи вашей системы в будущем.

чем больше абстракций навыделяете — тем больше и будет протечек в будущем.
примерно как чем больше строк кода — тем больше багов в нем.

за все надо платить.

Системную транзакцию не составит особого труда абстрагировать от реализации

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

И если новая БД не поддерживает транзакцию, то не беда, все будет работать.

а если поддерживает, то на кой абстрагирование?

например, паттерн Saga

Хороший паттерн. В сказках для начинающих — да, взял паттерн — и проблемы больше нет :)

С валидацией вообще не понятно, в чем проблема

потому что не сталкивались, вот и непонятно :)

большой корневой агрегат

книгу прочли — это правильное начало.
когда поймете почему без труда, «правильными паттернами» — проект не сделать, тогда и поймете почему наивно звучит

течь будет любое «плавучее средство», если его проектировать с дырками в дне :)
это в каких сказках выделяется достаточное время на это?

Явно не в сказках из аутсор мира.

в тех где абстракции не протекают, «если их правильно готовить»? ;)

В тех, где для забивания гвоздей не используют микроскоп.

чем больше абстракций навыделяете — тем больше и будет протечек в будущем.
примерно как чем больше строк кода — тем больше багов в нем.

за все надо платить.

так никто и не спорит, что для редактора БД с красивым фронт-эндом надо применять как можно больше абстракций.

да ну :D

Обычно баранки гну. Ну если по чесноку, то без базара ;)

Системную транзакцию не составит особого труда абстрагировать от реализации

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

По мне, так это задача посильна мидлу. Правда, у каждого свое понимание, что должен знать трейни, джуниор, мидл и синьор.

И если новая БД не поддерживает транзакцию, то не беда, все будет работать.

а если поддерживает, то на кой абстрагирование?

Согласен на все 100%, если система — удобный редактор конкретной БД. Или из мира аутсорса — наши 20 летние эксперты-синьоры могут реализовать вам софт любой сложности. Что? С долговременным развитием и поддержкой? Ну нет, это без нас.

например, паттерн Saga

Хороший паттерн. В сказках для начинающих — да, взял паттерн — и проблемы больше нет :)

С таким подходом любой принцип (например, SOLID), паттерн, архитектура — это из мира сказок. Это как в реальной жизни, поначалу кажется что все так просто — море по колено, горы по плечу. Ну а понимание реальности приходит по позже, с опытом.

С валидацией вообще не понятно, в чем проблема

потому что не сталкивались, вот и непонятно :)

Если для организации бизнес-логики используется доменная модель (в отличии, например, от скрипта транзакции), то конечно валидация должна быть в слое доменной модели. Как пример — можно ли валидировать на стороне фронтэнда? Да, конечно, но это не отменяет валидацию на стороне бекэнда.

большой корневой агрегат

книгу прочли — это правильное начало.
когда поймете почему без труда, «правильными паттернами» — проект не сделать, тогда и поймете почему наивно звучит

Книга о проектировании «правильными паттернами»? Типа Pattern Driven Design? Не, такое не читал :)

Явно не в сказках из аутсор мира.

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

уже просто в силу закона «работа занимает все отведенное ей время, независимо от количества этого времени и количества работы»

и по времени или деньгам половина айтипроектов выходят за рамки планов. а думаю больше чем в исследованиях, потому что в исследованиях сложно учесть успешные проекты, которые завершились вовремя потому что за борт была выброшена треть планируемого функционала, и во многих местах делать пришлось мимо бэст практик, «архитектур», SOLID, и т.п.

В тех, где для забивания гвоздей не используют микроскоп.

Абстракции дырявы по определению. На пальцах это и разъяснил Джоел Спольски

По мне, так это задача посильна мидлу.

и джун может код писать.

а если дать бесконечное количество времени — то и любой.

как вообще люди детектят опыт друг друга? очень просто — по недомолвках и умолчаниях.

головняк — это сделать нечто за ограниченное количество времени. и вот тут и проявляется разница, которая упоминается в «Факты и заблуждения профессионального программирования».
разница в продуктивности программистов, в 5 и больше раз, причем находящихся на одних и тех же должностях, примерно с одинаковым стажем, а не между «джунами» и «синьорами»

просто опустил. очевидно же что — ограничение по времени всегда присутствует. будь то при проектировании, будь то при латании «10летнего лэгаси».

а так да, согласен, и менеджменту так и говорю:

Любой программист может написать любую программу.

Правда, у каждого свое понимание, что должен знать трейни, джуниор, мидл и синьор.

тут да, правда. это зависит от того кто сам тот что рассуждает — джун, мидл или синьор.

С таким подходом любой принцип (например, SOLID), паттерн, архитектура — это из мира сказок.

сказки крайне важны для воспитания мировоззрения. это форма передачи знания.
но знания — не навык, не умение.

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

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

именно о том и написал.

Если для организации бизнес-логики используется доменная модель

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

Да, конечно, но это не отменяет валидацию на стороне бекэнда.

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

Кто сталкивался — знает, что просто не будет. Кто не сталкивался — не поймет вообще в чем проблема.
Я тоже не понимаю в чем проблема перебрать АКПП.

Книга о проектировании «правильными паттернами»? Типа Pattern Driven Design?

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

ну а о полезности и нужности карты, во всем, писал в исходном посте.
главное не перепутать соответствие точек на карте — местности по которой идешь.

тот кто думает что абстракции бывают НЕ дырявые — обязательно перепутает.
последствия зависят от уровня принятия решения.
обычно путающих выявляют, и не дают прав на принятие решений.

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

8 ловушек программирования, хабр
Признаки того, что вы в ловушке
• Написание универсального фреймворка перед реализацией основной функциональности, причем использоваться будет от силы 30% написанного кода
• Вера в то, что из любой проблемы лучший выход — использовать какой-либо паттерн
• Написание максимально обобщенной, принимающей все на свете и выдающей корректные результаты для любых входных значений функции, вместо специализированной, даже если ее функционал никогда не будет использован

не работал в аутсорсе, не знаю.

Я работал. Хватает негативного опыта, но и не только негативного. Как и в реальной жизни, нет простых ответов.

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

Обычно рассматривают треугольник с вершинами время, деньги, качество, в котором одновременно можно «оптимизировать» только 2-е вершины. IT разработка не такая сложная и специфичная вещь, что бы туда вводить понятие «люди».

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

детально не исследовал этот вопрос, но по ощущению, последние, как минимум, 10 лет проблема в основном в

Примерно тот же в подвох в управлении проектами, в выборе методологии и метрик управления.

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

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

В тех, где для забивания гвоздей не используют микроскоп.

Абстракции дырявы по определению. На пальцах это и разъяснил Джоел Спольски

Если для организации бизнес-логики используется доменная модель

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

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

ну а о полезности и нужности карты, во всем, писал в исходном посте.
главное не перепутать соответствие точек на карте — местности по которой идешь.

тот кто думает что абстракции бывают НЕ дырявые — обязательно перепутает.
последствия зависят от уровня принятия решения.
обычно путающих выявляют, и не дают прав на принятие решений.

Спорный/обсуждаемый вопрос. Смотря как вы воспринимаете абстракцию. Вот, например, высокоуровневые ЯП, ООП, ФП — чистые абстракции, как и алгоритмы, паттерны, архитектура. Я смотрю на абстракцию как на инструмент, который для определенных задач уместен, а для других — нет. Если, конечно, воспринимать любую абстракцию как карту для действий, и шаг влево/вправо — выстрел без предупреждения, то да, все абстракции текут.

По мне, так это задача посильна мидлу.

и джун может код писать.

а если дать бесконечное количество времени — то и любой.

Не согласен по поводу «бесконечное количество времени». Дали бы мне такую задачу с эстимейтом «бесконечное количество времени», я бы ее никогда не закончил, главное, что бы регулярно денюжку платили ;)

как вообще люди детектят опыт друг друга? очень просто — по недомолвках и умолчаниях.

Можно попытаться формализировать. Вот одна из попыток.

разница в продуктивности программистов, в 5 и больше раз, причем находящихся на одних и тех же должностях, примерно с одинаковым стажем, а не между «джунами» и «синьорами»

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

8 ловушек программирования, хабр
Признаки того, что вы в ловушке
* Написание универсального фреймворка перед реализацией основной функциональности, причем использоваться будет от силы 30% написанного кода
* Вера в то, что из любой проблемы лучший выход — использовать какой-либо паттерн
* Написание максимально обобщенной, принимающей все на свете и выдающей корректные результаты для любых входных значений функции, вместо специализированной, даже если ее функционал никогда не будет использован
  • «Написание универсального фреймворка» — согласен на все 100%. Есть куча проблем не только в применении методологий менеджмента, но и в применении/не применении методологий девелопмента.
  • «Вера в то, что из любой проблемы лучший выход — использовать какой-либо паттерн» — вера дело не надежное, и больше относится к иррациональному, чего не должно быть в нашей сфере :)
  • «Написание максимально обобщенной ...» - это то же самое, что и первое, но только на более нижнем/мелком уровне.
IT разработка не такая сложная и специфичная вещь, что бы туда вводить понятие «люди».

вообще-то люди — обязательно не только в IT. в материальном производстве добавляется еще 4ый ресурс, сырье-узлы

как мне просто пояснил один пиэм(из программистов), имея опыт работы и в строительстве(уходил на пару лет после кризиса 2008го), в проектном офисе,

в плане работ по супермаркету я могу написать: для таких то работ — «бригада в 5 маляров», время выполнения (ммм, что там в нормах, — о, Y дней)
а вот при разработке ПО «для реализации функционала X — 5 программистов» полная туфта и профанация. Надо учитывать — что это за 5 человек. Являются ли они одной командой. Какое качество кода проекта. Какие — архитектурные подходы приняты в проекте. и т.д.

так что я бы сказал о вашем заявлении тоже самое что и перед этим:
вы либо эксперт, матерый из 3% сверху, причем уже не только как архитектор, а как и менеджер программных проектов
либо обычный программист, «мидл» которые пока не сталкивался с неприятностями как котенок Гав.

или в желании распила бабла как со стороны заказчика,

ну эт понятно. одно из самых расхожих мнений о причинах провалов IT проектов среди обычных программистов.
заговор жидо-массонов кстати тоже причина бедствий

. Смотря как вы воспринимаете абстракцию.

как в словарях воспринимаю.
Абстра́кция (лат. abstractio — отвлечение) — теоретическое обобщение как результат абстрагирования.
Абстрагирование — отвлечение в процессе познания от несущественных сторон, свойств, связей объекта (предмета или явления) с целью выделения их существенных, закономерных признаков. Результат абстрагирования — абстрактные понятия,

Я смотрю на абстракцию как на инструмент

чего — инструмент?
Познания, систематизации знаний.

Программный же код — это всегда конкретика. В нем всегда будет то чего нет в исходной абстракции, которую он описывает.

Дали бы мне такую задачу с эстимейтом «бесконечное количество времени», я бы ее никогда не закончил

закончили бы. заканчивают проекты и просто с увеличенным в пару раз временем, те же программисты.

Можно попытаться формализировать. Вот одна из попыток.

Формализация не имеет отношения к тому что я сказал об умолчаниях.

Как-то один в меру известный рассказал историю, когда он поступал на мехмат, МГУ
у него в семье были математики, и он конечно неплохо знал, но главное — наслышался профессионального сленга профессиональных математиков.
И когда пояснял экзаменатору свое решение, случайно вворачивал эти словечки и выражения вместо книжных. Которых нет ни в одном учебнике или монографии по математике.
Экзаменатор был в восторге.
— Ваши учителя отлично знали математику и были хорошими педагогами. У вас прекрасная математическая подготовка!

Я об этом, «форумном» формате, «за пивом»

вера дело не надежное,

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

Но, еще вид оценки по «недомолвкам и умолчаниям»
Цинизм — это отрыжка опыта.

Не всегда циник это опытный.
Но опытный — всегда будет немножко циником.
В мягкой, корректной форме — прагматиком.
У опытного — всегда будет тяга к черному юмору, и т.п.
В любом деле.

Девочки эйчарши нередко цинизм опытного записывают в токсичность, отсутствие оптимизма и прочая. ну, правильно, у них же пока нет неформального опыта общения с опытными, за исключением мамы-папы. «взрослые» с ними, при них, еще не общались как между собой :)
А ребята у нас в айти — тоже в основном молодые :)

Теория спасает от грубейших ошибок. От гарантированных фейлов.
Но успех — за ее возможностями. Успех это из разряда — «оказаться в нужном месте в нужное время». Хорошая карта может помочь выявить эти — места. Но неточно: клад закопан на этой поляне. Вот те лопата — выкопай его до завтра.

а вот при разработке ПО «для реализации функционала X — 5 программистов» полная туфта и профанация. Надо учитывать — что это за 5 человек. Являются ли они одной командой. Какое качество кода проекта. Какие — архитектурные подходы приняты в проекте. и т.д.

Согласен, «люди» важны, если проект на пару месяцев или пол года. Обычно что-то совсем маленькое и дешевое, не требующее качество. А вот если проект на годы, то в этом случаи не важно. Даже если у вас нет команды, вы всегда сможете ее нанять, главное, что бы бюджет позволял. «Люди» важны в стратапе на наальных этапах, но это «чуть-чуть» не только о разработке.

вы либо эксперт, матерый из 3% сверху, причем уже не только как архитектор, а как и менеджер программных проектов
либо обычный программист, «мидл» которые пока не сталкивался с неприятностями как котенок Гав.

Ну вот без оценки совсем ни как. Нет, что бы объективно обсудить вопросы. Да, я счиатю себя экспертом. Менеджментом не занимаюсь, т.к. это не мое. Как влияет моя самооценка на обсуждаемые вопросы?

или в желании распила бабла как со стороны заказчика,

ну эт понятно. одно из самых расхожих мнений о причинах провалов IT проектов среди обычных программистов.
заговор жидо-массонов кстати тоже причина бедствий

Ну так это из реальной жизни. И проект не был провальным, но его бизнес-валью стремилось к 0.

Смотря как вы воспринимаете абстракцию.

как в словарях воспринимаю.
Абстра́кция (лат. abstractio — отвлечение) — теоретическое обобщение как результат абстрагирования.
Абстрагирование — отвлечение в процессе познания от несущественных сторон, свойств, связей объекта (предмета или явления) с целью выделения их существенных, закономерных признаков. Результат абстрагирования — абстрактные понятия,

И где тут «течь»?

Я смотрю на абстракцию как на инструмент

чего — инструмент?
Познания, систематизации знаний.

Программный же код — это всегда конкретика. В нем всегда будет то чего нет в исходной абстракции, которую он описывает.

Инструмент создания исходного кода. Чего же еще? И да, исходный код далеко не всегда конкретен — в нем может быть очень много неоднозначностей в зависимоти от выбранной, часто абстрактной :), точки зрения.

закончили бы. заканчивают проекты и просто с увеличенным в пару раз временем, те же программисты.

Это был юмор. Но с матиматической точки зрения понятие «бесконечное количество времени», т.е. вечно, не должно вести к какому-либо концу во времени.

вера дело не надежное,

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

Вот тут я абсолютно честен. Веру воспринимаю только в личных отношениях. И когда я начинал, особо и не было книг по паттернам, всяким разным архитектурам и т.п. И, если использовал что-то, то пытался добраться до сути. Например, в свое время книгу переваривал около 2-ух лет. Так все и не допереварилось, пока не начал вникать в DDD — более базовые «абстракции».

Теория спасает от грубейших ошибок. От гарантированных фейлов.
Но успех — за ее возможностями. Успех это из разряда — «оказаться в нужном месте в нужное время». Хорошая карта может помочь выявить эти — места. Но неточно: клад закопан на этой поляне. Вот те лопата — выкопай его до завтра.

Не совсем понял. По мне, так теория без практики так и останется только теорией. Если не начать использовать/применять различные эти абстракции — ООП, ФП, парттерны, архитектуры, то они так и останутся протекающими абстракциями.

Да, я счиатю себя экспертом

а я не считаю себя экспертом.

поэтому «умолкаю и внимаю» Вашему Мнению.

особенно если

в свое время книгу переваривал около 2-ух лет.

но не поняли почему абстракции текут. гарантировано и всегда.

Да, конечно, но это не отменяет валидацию на стороне бекэнда.

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

Кто сталкивался — знает, что просто не будет. Кто не сталкивался — не поймет вообще в чем проблема.
Я тоже не понимаю в чем проблема перебрать АКПП.

Да согласен, валидация бывает разная. Например, девелопим HTTP API, который работает на HTTP протоколе, который реализован поверх TCP. Можно обсуждаит валидацию запроса на соответсвие HTTP. Но в статье четко заданы границы:

Не очевидно, где именно должны быть валидации? С одной стороны, валидация — это часть бизнес-логики и должна жить в Аpplication core. С другой стороны, слои должны быть максимально независимы со своей валидацией на каждом уровне. Или достаточно проверить так где они приходят — на первичных адаптерах? Тут нет правильного ответа, выбирайте то, что больше подойдет вашему приложению.

З.Ы. валидация, например, данных уровня транспорта, которую надо реализовывать на транспортном уровне (почти масло масляное), ни как не отменяет бизнес-валидацию на соответствующем уровне в зависимости от выбранной архитектуры.

Можно обсуждаит валидацию запроса на соответсвие HTTP.

зачем? в любом приличном фреймворке это давно реализовано.

девелопим HTTP API, который работает на HTTP протоколе, который реализован поверх TCP.

не писал свою реалиазацию.

Спецификация HTTP в открытом доступе, но опять же, не вчитывался при проектировании API, потому что это реализовано в фреймворках которые использовались.

ни как не отменяет бизнес-валидацию на соответсвующем уровне в зависимости от выбранной архитектуры.

Небо голубое, трава зеленая. да, полностью согласен

там же, важное:

Тут нет правильного ответа, выбирайте то, что больше подойдет вашему приложению.

проектирование ПО — еще дальше от однозначности и строгости математики чем программирование.

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

зачем? в любом приличном фреймворке это давно реализовано.

Так и я о том же. Какое все это имеет отношение к проблеме валидации в статье?

Какое все это имеет отношение к проблеме валидации в статье?

Валидация существует не только в этой статье :)

Но абстракция у вас уже потекла, вам уже нужна конкретика: статья, HTTP, ... ;)

хотя в статье

валидация — это часть бизнес-логики

а бизнес-логика — обычно базируется на персистентно хранимых данных.
А между входящим HTTP запросом и системой хранения данных — сколько слоев приложения? в простом — 1 точно будет

поняли в чем проблема?

так же и с транзакциями, любыми, которые — отсутствуют в понятиях домена.
оно ортогональны большинству архитектур
при этом есть фундаментальная невозможность точного объектно-реляционного преобразования.

поняли в чем проблема?

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

и легко решает эти проблемы либо эксперт, топовый специалист, либо тот кто не решал их :)
остальные решают — с головняком, инженерной смекалкой и интуицией, танцами с бубном, и т.п.
потому что проблемы то эти — фундаментальны ;)

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

Какое все это имеет отношение к проблеме валидации в статье?

Валидация существует не только в этой статье :)

Но абстракция у вас уже потекла, вам уже нужна конкретика: статья, HTTP, ... ;)

Как то не заметил, какая именно протекла? Абстрактная валидация или валидация-бизнес логики?

а бизнес-логика — обычно базируется на персистентно хранимых данных.

Не обязательно. Например, получили запрос, провалидировали, обработали на основе заданной бизнес-логики, и отправили его другой подсистеме. Можно и дальше придумывать различные абстрактные! варианты :). Но какое это имеет отношение к вопросу валидации в статье?

поняли в чем проблема?

Я не понял, какая проблема рассматривается? Валидация взагали, во всех ее проявлениях? И все возможные ее реализации — как «вменяемые», так и не только? И да, тут еще надо определиться с абстарктным! (или субъективным?) критерием «вменяемости».

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

Так это вы не совсем понимаете назначение корневого агрегата и как он связан с транзакциями.

при этом есть фундаментальная невозможность точного объектно-реляционного преобразования.

Ну так мир не заканчивается на реляционных БД. Как вариант — ORM вам в помощь — решает большинство проблем преобразованиями.

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

Вы можете строить домен один в один к реляционной модели, никто вам это не запрещает. Но, похоже, вы не поняли сути архитектуры «Порты и адаптеры». Особенно, так называемых в статье, «вторичных адаптеров». И да, может быть я потерял какую-то важную суть, но я не помню, что бы мы поднимали вопросы о фундаментальных проблем ¯\_(ツ)_/¯

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

Люто бешено плюсую, я всем коллегам пытаюсь донести простую мысль, что нужна не бюрократия, а повышение эффективности труда/эргономики разработки для команды.

а повышение эффективности труда/эргономики разработки для команды.

а коллегам зачем? они не поймут, до определенного уровня развития как программисты.

это менеджменту нужно доностить разницу между бюрократией, и методами повышения эффективности разработчиков.
иногда да, нужно это доносить и до архитектурных астронавтов :)

но это сложно млин. поди объясни менеджменту или заигравшемуся архитектору о способах снижения когнити́вной нагру́зки программистов. особенно, как выше упомянул, когда сами программисты не понимают что увлечение слоями абстракций — увеличивает эту нагрузку :)

Мои коллеги, на одном уровне это как раз менеджмент и архитекторы)

а, да, извините, тупанул.

тогда да, это и есть печаль что

я всем коллегам пытаюсь донести простую мысль,

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

Не очень понял, при чем тут Node.js (ну кроме того, что примеры на JS)? А вообще, абстрагироваться тоже нужно до какого-то разумного предела. Иначе в погоне за супер-чистой абстракцией, можно потерять преимущества конкретного сервиса/платформы и тогда вреда будет больше чем пользы. Нет смысла затачиваться под некую «усредненную базу данных». Мало какой продукт будет прыгать с SQL Server, на MySQL, затем на Oracle, а потом на Mongo. Зато каждый из продуктов дает какие-то свои специфические фичи, которые могут быть весьма полезны. Это как пример.

Нет смысла затачиваться под некую «усредненную базу данных». Мало какой продукт будет прыгать с SQL Server, на MySQL, затем на Oracle, а потом на Mongo.

Довольно много продуктов прыгают с SQL Server/Oracle на PostgreSQL/MySQL, c MySQL на PostgreSQL, с SQL на No SQL. И очень часто из-за отсутствия абстракций, миграции с одной SQL БД на другую худо-бедно, больно и геморойно проходит с первоначальной кодовой базы. То переход на No SQL часто проводится типа «а давайте все это нах перепишем с нуля».

З.Ы. сейчас рефакторю проект, который 2 года назад мигрировал с SQL на Mongo. Качество перехода ужасает.

который 2 года назад мигрировал с SQL на Mongo. Качество перехода ужасает.

вполне вероятно что сама причина миграции такая же — «ужасная».

То переход на No SQL часто проводится типа «а давайте все это нах перепишем с нуля».

правильно. потому что если абстрагироваться от всего и вся — то получим тьму слоев абстракции и неэффективность рантайма. при том что в слоях этих быстро начнет съезжать крыша у всех, и слои будут протекать. и тяжесть поддержки, а главное — развития, станет ничуть не лечге в сравнении с «хяк-хяк и в продакшн» и копипаста кода

SQL Server/Oracle на PostgreSQL/MySQL, c MySQL на PostgreSQL

это уже гораздо легче, чем с реляционной БД переходить на нерялицонную

По поводу абстракций — все зависит от проекта. Для редактора/вювера БД не нужны ни какие доменные модели, порты и адаптеры и т.п., как может показаться, мишура.

github.com/...​s/EventCreationService.ts

Разве Converter не нужно на уровень выше поднять, в контроллер?
Например, нужно будет создать Event для другого типа эндпоинта, где формат ответа будет отличаться.

Это базис, но оформлена статья хорошо, спасибо.

октагональная?

Нууу, вот у меня тоже вопрос.

Почему в заголовке статьи про гексагональную архитектуру а в самой статье октагональные примеры :)

А вообще словосочетание «гексагональная... node.js» сходу вызвало мысль «а гексагональная это потому что логотип сота или как?» :)

Потому, что в оригинале было примерно так:
hexagonkt.com/img/architecture.svg

Но автор статьи добавил портов и адаптеров, и шестиугольника перестало хватать :)

Подписаться на комментарии