привет как раз сегодня еще одна интервью тогда представься и скажи на чем пишешь да я пишу я на ноги могу писать какие бак таки фронтом работ этот вкус так разработчик ты мне уже заранее сказал что вы используете гексагональную архитектуру в проектах да поэтому может быть ты скажешь откуда она возникла и на что она похожа то есть на что она похожа в классическом в классических архитектурах потому что это же на самом деле некоторые развития классических подходов и возможно ну расскажешь более подробно из чего
00:00:00 - 00:01:53
состоит собственно сама архитектура ну вот как бы что она предполагает какие какие на абстракции предполагает конечно с того что она не для новичков есть немного попроще архитектуры однако она очень сильно помогает когда у вас есть большой брат им вам сложно разделять логику потому что у вас есть несколько входов разные клиенты типы это может быть какие white такие файлы и запрос из разных ресурсов таком случае как школьная как сакральная архитектура предоставляет нам абстрагирование логике от входа и также
00:00:57 - 00:02:38
от выходом когда вам мы акцентируем бизнеса логику в одном центре [музыка] треугольная почему-то мне 10 угольное мы точно не знаем но если представить ее в на картинке больше все случай будет какой-то шестигранник потому что у нас с одной стороны таскать три вершины которые петляет масса клиента входы а другие а также будет выходы в какие-то базы данных или в другие вообще другие сервисы которые не любое название пруссию очень часто можно встретить под таким названием как архитектура портов и адаптеров вот
00:01:49 - 00:03:32
раскрой пожалуйста это конечно вот я уже рассказал что у нас есть бизнес логика центр вот это бизнес логики у нас могут быть несколько портов а то есть на шею ходе которые проходят через адаптеры которые преобразуют данные в определенных структур и которая понятна для нашего ядра и тогда уже придут и и ведро то есть ядро принимает данные определенные три типа адаптеры принимает те данные которые ожидайте трасс имеют лифте данные которые хочет ядро также с выходами мы когда отсылаем из ведра какие-то данные у нас могут стоят
00:02:41 - 00:04:09
адаптеры большинстве случае не есть который преобразует эти данные в данные которые потребуют тот ресурс кантами отсылаем то есть например смеха там мы можем сказать что на сессия мамка которая не лицевыми база и паскарь с которой ле-цион вот у нас будут 2 адаптера для каждой базы данных которые придут их нужный формат окей а значит все вот эти вот адаптеры они делятся на два вида есть те которые собственно мы их вызываем а есть такие которые нас вызывают слышал я слышу но одни как-то называются ну это баста
00:03:25 - 00:05:12
ну то есть шины и вот наружная как бы сказать оболочка вот все это бизнес логики которая связывает собственно адаптер с периферией там какими-то удаленными а пешками системами удаленными там какими-то очередями или же какими-то сервисами которые мы вызываем наружу вот субд этом может быть какие-то шлюзы какие то значит там mail gateway там и прочее такая штука та часть из них нас вызывают часть мы вызываем и вот собственно они вне что еще так делятся в таком случае я предпочитаю более остроги рация
00:04:18 - 00:05:53
этого использовать какой-то message broker и уже по командам когда нужно какому-то внешнему сервисом нужны данные о на проект команду и на через адаптер пропустим к этому сервису так снова и вообще зачем нужен адаптер вот какой его смысл ну и как это связано с пешком паттерном адаптер может быть связано может нет как ты это себе представляешь пока попробую ответить на 1 это довольно просто когда у нас есть большая логика но вместо того чтобы ее каждый раз лезь к ней чтобы подправить код капот нужного
00:05:09 - 00:06:31
клиента под нужный вход мы просто на верхний слой и добавим адаптер к входу к яге больные в я друг уже были будут отсылаться можно формате там намного проще мы не лезем в нашу логику а настраиваем слой с работой с клиентом то есть другими словами субстрат абтар нужен для изоляции слоев чтобы у нас они не перемешивались и знали друг о друге только контракт то есть только минимум знали это еще можно выразить по-другому есть такой такие понятия коупленд и к fashion вот как это связано с ними может быть
00:05:51 - 00:07:31
слабая тесная связанность то что если у нас сущность имеет определенный ответственность тогда она должна быть слабо связаны с сущностью которая имеет совсем другой ответственности в этом случае вносить клиент из логика и конечно же мы не хотим чтобы они были связаны а потому мы создадим адаптеры и растяжение ok и ты еще говорил что вы используете граф кейн и вот интересно как он вписывается в эту гексагональную архитектуру потому что в принципе вот на мой взгляд он достаточно далеко от него стоит и и
00:06:43 - 00:08:09
это немножко разные подходы какое-то объединяете очень интересно да вот в этом случае уже можно при помощи кирас потому что на графике алина smpp резона которые могут вызвать создание команды случае которые уже будет i want команда создаст иван и вот от после этого иван то у нас есть несколько сервисов которые могут как-то себя повести и вот они уже пойдут через адаптер ядро чтобы определить какой именно реагировать и при некоторых состояния проекта и вот паттерн secures он часто используется вместе с еще одним
00:07:29 - 00:09:34
паттерном нас нет и windows and seek весит расскажем так опыт этот паттерн то есть крс это же у нас архитектурный поттер правильно osiris это ну такая техника программирования у пышная но которая из которой secures принципе родился но вместе же они не используются это сказать про его из вас нет я могу рассказать как он связан и почему именно они используются вместе но связывает их уважаем простой его секрет создает их оуэнс arsenka можно сказать проще сохраняет чтобы потом по этим ивентом можно было
00:08:36 - 00:10:18
воссоздать то состояние которое было в определённый момент времени мы вообще ну я думаю каждый сможет сразу себе предмет пример что когда у нас есть какой-то бах и вот никак там пологом вы не может определить можно банально создать себя даже наконец то же самое состояние к определенной точке времени и воссоздать тот event который создал ошибку и так будет проще зад и пожить еще до есть например и миграции которые усики раз уже есть фракции которые создаются из-за иван там и вот когда вам нужно что-то
00:09:33 - 00:11:01
перемоделировать он не нужно будет смотреть каждой сущностью изменять просто измените артем структурой и вольтер и после миграции вас просто после каждой ванда будут носиться изменения в проекцию и фракции уже поправиться под нужный формат так ну вот ты расскажешь что-нибудь про внедрение зависимостей вот может быть это как-то используется у вас проектах ну когда же сми сейчас ментальности репозитория мне нравится но большинстве случаев нас используется [музыка] наследование мы называем базовой структурой и от них мы
00:10:24 - 00:12:02
сливаемся и при этом имеем доступ к родительским методом которые упрощают работу с серовым или классом даже ну вообще для гексагональной архитектуры характерная инверсии управление они наследования . наследование может быть там в классах доменной логике но каким образом там ссылки на инстанции классов которые являются периферии и значит находится на наружных слоях попадают в бизнес-логику если мы хотим что-нибудь сделать из бизнес-логики из там из кейсов из сервисов направо по штатам доступ например с
00:11:19 - 00:13:06
одного сервиса к другому как криптографический сервис какой-то и он ну это сервис сервис не касающейся доменной логике то есть он где-то на периферии находится а нам нужно к нему обращаться причем желательно так чтобы можно было его подменить в любой момент вот из бизнес-логики нам нужно что-то зашифровать но чтобы не не реализовывать это шифрование внутри и чтобы как можно меньше знал бизнес-логика о том как происходит шифрование ну если а там пришли к сервису который хорошо о своем остался в котором видим
00:12:15 - 00:13:54
прощаемся тонн большинстве случаев это будет реализованы при помощи микро сервисной архитектура когда мы будем отдельно сервер запрашивает но к нему делать запрос также можно запрашивать через очки запросам просто в таком случае нам надо будет реализовать ну какой то чтобы проверять можно ли брать ты когда-нибудь писал приложение или может быть читал какую-то литературу по чистой архитектуре клин архитектор смотри вот чтобы лучше понимать гексагональную я тебе с самого начала спросил из чего она вышла она на самом
00:13:05 - 00:14:48
деле вышло из слоеной архитектуры которая уже сто лет в общем исполнилось и одной из реализацией слоеная архитектура является вот чистая архитектура это как бы это условное название естественно потому что в принципе почти все что мы не возьмем все равно будет с военной архитектуры другой архитектуры кроме вот слоеной и pipeline сложно себе вообще представить на самом деле гексагональной это тоже какая-то реинкарнация слоеное ли чистые архитектуры просто в которой у нас очень четко определены там
00:13:58 - 00:15:31
порты и адаптеры и на самом деле ты говоришь что это сложная архитектура не для новичков тоже такой вот взгляд но мне кажется что наоборот гексагональной архитектуре очень много всего определено всяких рекомендаций всяких методологии всякой и ну очень сильно расписано из каких компонентов архитектура состоит в в слоеной ну просто говорится что вот нужно писать свои так чтобы они были изолированы как меньше как можно меньше перемешивали а из каких компонентов и какими способами там вот ну инверсии
00:14:44 - 00:16:11
управления там это значит как зависимости внедряются или как там допустим происходит обмен данными или там нужны ли адаптер и там или там значит когда мы через вызовы и интегрируем ся когда мы через событие но не не ничего не сказано об этом то есть выбирайте те способы какие хотите а если начать с чистой архитектуры и все почитать книжечки из которых это все вышло мне кажется что откроются ну основные идеи которые за всем этим лежат и вообще так конечно же гексагональной архитектура она для новичка проще потому что более
00:15:27 - 00:16:57
понятно все более расписано конечно же ну ты наверно сравнивал с тем как писать вообще без архитектуры понятное дело что с хоть какой-то архитектурой писать но это сложнее и это для более продвинутых людей но гексагональной специально вот так вот разжевывает все и дает шаблоны практически для всех частей приложения чтобы в общем человеку меньше было задумываться когда он начинает что-то писать это такая вот рекомендация посмотреть в сторону чистые архитектуры и слоеной архитектуры еще чтобы лучше
00:16:12 - 00:17:31
понимать гексагональную если уж ты ее использую сейчас проектах это так лекции по этому есть я сказал сложный потому что большинство из начинаю щитом абатура немножко могут трудностям они расписаны вот как сказали что там делай что хочешь и данные которые приходят и которые нужно брать может быть очень сложно распарсить ну вот собственно да начинающему проще всего писать без архитектуры просто начали пить все как попало и не думать про зацепление связанность там еще все вот эти вот аспекты и не разделять свои ну
00:16:52 - 00:18:19
как так но это просто дикое программирование без без архитектурная ну конечно она проще чтоб код писать но поддерживать такую систему это вообще полный от ну и может быть ты еще расскажешь про фронт и я так понимаю что это у вас тоже на фронте используются реакций и возможность серверами в гексагональной архитектуре вот скажем так как он вписывается во всю эту систему и можно ли вообще где-то в гексагональной архитектуре разместить где место пользовательских интерфейсов и вообще значит может быть там франта или
00:17:36 - 00:19:15
там значит вы оба реактор на четыре трубки то angular а или веб-компонентов так ну в общем всего вот это вот небо сам фронтом будет размещен за границами нашего шестигранника потому что как мне рассказали как закон архитектурой на сессии draw me to бизнес-логика и нынешний слоя характер и поэтому мы не должно быть связано с [музыка] бизнес-логика и вот мое предпочтение это создать им отдельный сервер просто который будет хиндли то я уже оттуда будет ссылаться запрос сама проекта через адаптер в каком-то реактор скам приложение там
00:18:25 - 00:20:07
же может быть часть бизнес-логики написан вообще как бы она свойственна только для клиентского приложения она там не серверная логика вот что получается нам нужно еще одну еще одно приложение отдельные тоже по гексагональной архитектуре или по какой-то другой архитектуре еще одно приложение делать на фронте и просто связывать одно приложение с другим или или как вот или она все-таки как-то вписывается ну то есть если нужно допустим что-то вычислять или часть бизнес-логики исполнять на фронте вот как тут быть
00:19:25 - 00:20:55
использованы красных архитектура и создал бы просто решили сервис которому бы обращался с manta для того чтобы вычислить некоторые данные и сказали поборы в нашем внедрение можно будет нет смотри я имею в виду что у нас есть пользовательский интерфейс и в пользовательском интерфейсе вот часть логике она может повторяться с той логикой которая допустим на сервере находится примерно вот допустим электронные таблицы вот мы делаем себе приложение для электронных таблиц у нас есть какой то значит движок для
00:20:13 - 00:21:37
вычисления реактивных вот этих ячеек с экспресс и нами на сервере и мы к нему присылаем данные собственно когда ищейка там меняется и все это может работать на сервере но при этом гонять все все время как только мы поменяли ячейку между сервером и клиентом не очень хотелось бы мы хотели бы все вот это дело еще для упрощения просто запускать на клиентской части ну конечно как только ячейка поменялось мы ее отправляем на сервер но все вычисления мы хотим обсчитать то клиенте ну это получается некоторое дублирование то есть
00:20:55 - 00:22:17
получается бизнес логика у нас два раза реализовано или как если это какой-то малая часть кода тогда думаю не будет ничего страшно если мы повторим то есть там два три файла как бы спрятать а если вы не хотим не хотим повторять какие у нас есть выходы и может быть что-то у тебя встречалась в работе такое что вот дублируется между сервером и клиентом таком случае у нас на наш проект должен будет отсылать юань и ну просто без адаптера будем тогда стоять переданы ну ну это может быть ты тогда расскажешь
00:21:36 - 00:23:03
каким образом из реактора мы осуществляем доступ к данным зачем нам нужны менеджеры состояния как можно обойтись без них и вот как это все может быть связано в одном приложении с реакторов целям и гексагональные сервером совсем понял вопрос как это все можно увязать все эти компоненты в один проект фронт на reactie менеджеры состояний возможно граф кель и сервер backend гексагональной в таком случае я думаю нам фронт для фонтан надо бы это какой-то мега сервис история отдельный сервис который будет
00:22:27 - 00:24:12
отсылать лайку оттуда у нас будет идти игра в теле запроса на какой-то 1point от даже может быть адаптер продать своего рода и сервис получится а потом не совсем прикольно вот так но если все же адаптер тогда тут просто с адаптером и будем ведь в бизнес-логику если же адаптер тогда этого наша it service on point будет запрос уже наш бизнес лодке через адаптер для меня об этом представления фронт будет как отдельный такой пучок от шестигранника который будет через что-то по 1 ok какие могут быть
00:23:20 - 00:25:09
оптимизацией чтобы мы снизили количество запросов и вообще обменов данными между фронтэнда и сервером ну может быть такую знаешь проблему n + 1 проблема как мы знаем у покрыли проблему на сумму нарушается кашин право не случай когда много там пользователи часто данные меняется тогда как нам не сильно поможет но можно кешировать были на серверном уровне чтобы время запроса было меньше ну в общем давай уже подытожим все это дело смотри у тебя явно есть широкий опыт и знания но только в той сфере который
00:24:17 - 00:26:09
касается конкретно ваших в общем архитектурных решений которые в проектах используются для того чтобы это как-то расширить и осознать место всех этих архитектурных решений вообще в принципе в во всем многообразии того что у нас имеется инструментария и вообще технологии то мне кажется что нужно во-первых подсчитать книжечек по всем этим вещам ну то есть ты сейчас учишь все из практики и вряд ли открываешь статьи по каким-то смежным или совсем не похожим технологиям она на самом деле полезно чтобы понимать какие есть альтернативы
00:25:12 - 00:26:56
ну и мне кажется что нужно еще побольше смотреть докладов на конференциях потому что ну на самом деле мы все самое новое мы даже не из книжек узнаем о узнаем из того что вот кто-то в каком-то проекте другом там не нашим или значит где-то кто-то значит что-то изобрел или же переосмыслил или же значит появилась какая-то новый подход и сначала появляется доклад потом появляется статье и только потом появляются книжки уже через там какое-то количество лет но конечно нужно вот на все эти три вещи тоже уделять время то есть доклады
00:26:05 - 00:27:50
статьи и книжки чтобы иметь широкий кругозор в всем инструментарий и все многообразие технологии ну где-то так так что а ну еще в общем ты иногда когда объясняешь ну чувствуется что ты понимаешь но при этом высказать словами это у тебя тяжко выходит поэтому мне кажется что нужно тренироваться объяснять возможно вы в коллективе мало взаимодействуете мало или может быть ты значит на в коллективе всегда есть какие то люди которые больше говорят да вот и наверное больше слушаешь мне кажется что нужно может быть завести вам в
00:26:56 - 00:28:44
коллективе такое обыкновение иногда делать внутренние какие-то этапы и объяснять значит тут кто-то узнал что-то новое и там на 20-30 минут объяснил всем остальным ну так будет развиваться навык того что выражение собственно понятными словами концепции идей которые где-то почерпнули и так будет гораздо проще потом разговаривать даже о тех технологиях которые вы внутри используете это просто совет ну понял специально
привет как раз сегодня еще одна интервью тогда представься и скажи на чем пишешь да я пишу я на ноги могу писать какие бак таки фронтом работ этот вкус так разработчик ты мне уже заранее сказал что вы используете гексагональную архитектуру в проектах да поэтому может быть ты скажешь откуда она возникла и на что она похожа то есть на что она похожа в классическом в классических архитектурах потому что это же на самом деле некоторые развития классических подходов и возможно ну расскажешь более подробно из чего
00:00:00 - 00:01:53
состоит собственно сама архитектура ну вот как бы что она предполагает какие какие на абстракции предполагает конечно с того что она не для новичков есть немного попроще архитектуры однако она очень сильно помогает когда у вас есть большой брат им вам сложно разделять логику потому что у вас есть несколько входов разные клиенты типы это может быть какие white такие файлы и запрос из разных ресурсов таком случае как школьная как сакральная архитектура предоставляет нам абстрагирование логике от входа и также
00:00:57 - 00:02:38
от выходом когда вам мы акцентируем бизнеса логику в одном центре [музыка] треугольная почему-то мне 10 угольное мы точно не знаем но если представить ее в на картинке больше все случай будет какой-то шестигранник потому что у нас с одной стороны таскать три вершины которые петляет масса клиента входы а другие а также будет выходы в какие-то базы данных или в другие вообще другие сервисы которые не любое название пруссию очень часто можно встретить под таким названием как архитектура портов и адаптеров вот
00:01:49 - 00:03:32
раскрой пожалуйста это конечно вот я уже рассказал что у нас есть бизнес логика центр вот это бизнес логики у нас могут быть несколько портов а то есть на шею ходе которые проходят через адаптеры которые преобразуют данные в определенных структур и которая понятна для нашего ядра и тогда уже придут и и ведро то есть ядро принимает данные определенные три типа адаптеры принимает те данные которые ожидайте трасс имеют лифте данные которые хочет ядро также с выходами мы когда отсылаем из ведра какие-то данные у нас могут стоят
00:02:41 - 00:04:09
адаптеры большинстве случае не есть который преобразует эти данные в данные которые потребуют тот ресурс кантами отсылаем то есть например смеха там мы можем сказать что на сессия мамка которая не лицевыми база и паскарь с которой ле-цион вот у нас будут 2 адаптера для каждой базы данных которые придут их нужный формат окей а значит все вот эти вот адаптеры они делятся на два вида есть те которые собственно мы их вызываем а есть такие которые нас вызывают слышал я слышу но одни как-то называются ну это баста
00:03:25 - 00:05:12
ну то есть шины и вот наружная как бы сказать оболочка вот все это бизнес логики которая связывает собственно адаптер с периферией там какими-то удаленными а пешками системами удаленными там какими-то очередями или же какими-то сервисами которые мы вызываем наружу вот субд этом может быть какие-то шлюзы какие то значит там mail gateway там и прочее такая штука та часть из них нас вызывают часть мы вызываем и вот собственно они вне что еще так делятся в таком случае я предпочитаю более остроги рация
00:04:18 - 00:05:53
этого использовать какой-то message broker и уже по командам когда нужно какому-то внешнему сервисом нужны данные о на проект команду и на через адаптер пропустим к этому сервису так снова и вообще зачем нужен адаптер вот какой его смысл ну и как это связано с пешком паттерном адаптер может быть связано может нет как ты это себе представляешь пока попробую ответить на 1 это довольно просто когда у нас есть большая логика но вместо того чтобы ее каждый раз лезь к ней чтобы подправить код капот нужного
00:05:09 - 00:06:31
клиента под нужный вход мы просто на верхний слой и добавим адаптер к входу к яге больные в я друг уже были будут отсылаться можно формате там намного проще мы не лезем в нашу логику а настраиваем слой с работой с клиентом то есть другими словами субстрат абтар нужен для изоляции слоев чтобы у нас они не перемешивались и знали друг о друге только контракт то есть только минимум знали это еще можно выразить по-другому есть такой такие понятия коупленд и к fashion вот как это связано с ними может быть
00:05:51 - 00:07:31
слабая тесная связанность то что если у нас сущность имеет определенный ответственность тогда она должна быть слабо связаны с сущностью которая имеет совсем другой ответственности в этом случае вносить клиент из логика и конечно же мы не хотим чтобы они были связаны а потому мы создадим адаптеры и растяжение ok и ты еще говорил что вы используете граф кейн и вот интересно как он вписывается в эту гексагональную архитектуру потому что в принципе вот на мой взгляд он достаточно далеко от него стоит и и
00:06:43 - 00:08:09
это немножко разные подходы какое-то объединяете очень интересно да вот в этом случае уже можно при помощи кирас потому что на графике алина smpp резона которые могут вызвать создание команды случае которые уже будет i want команда создаст иван и вот от после этого иван то у нас есть несколько сервисов которые могут как-то себя повести и вот они уже пойдут через адаптер ядро чтобы определить какой именно реагировать и при некоторых состояния проекта и вот паттерн secures он часто используется вместе с еще одним
00:07:29 - 00:09:34
паттерном нас нет и windows and seek весит расскажем так опыт этот паттерн то есть крс это же у нас архитектурный поттер правильно osiris это ну такая техника программирования у пышная но которая из которой secures принципе родился но вместе же они не используются это сказать про его из вас нет я могу рассказать как он связан и почему именно они используются вместе но связывает их уважаем простой его секрет создает их оуэнс arsenka можно сказать проще сохраняет чтобы потом по этим ивентом можно было
00:08:36 - 00:10:18
воссоздать то состояние которое было в определённый момент времени мы вообще ну я думаю каждый сможет сразу себе предмет пример что когда у нас есть какой-то бах и вот никак там пологом вы не может определить можно банально создать себя даже наконец то же самое состояние к определенной точке времени и воссоздать тот event который создал ошибку и так будет проще зад и пожить еще до есть например и миграции которые усики раз уже есть фракции которые создаются из-за иван там и вот когда вам нужно что-то
00:09:33 - 00:11:01
перемоделировать он не нужно будет смотреть каждой сущностью изменять просто измените артем структурой и вольтер и после миграции вас просто после каждой ванда будут носиться изменения в проекцию и фракции уже поправиться под нужный формат так ну вот ты расскажешь что-нибудь про внедрение зависимостей вот может быть это как-то используется у вас проектах ну когда же сми сейчас ментальности репозитория мне нравится но большинстве случаев нас используется [музыка] наследование мы называем базовой структурой и от них мы
00:10:24 - 00:12:02
сливаемся и при этом имеем доступ к родительским методом которые упрощают работу с серовым или классом даже ну вообще для гексагональной архитектуры характерная инверсии управление они наследования . наследование может быть там в классах доменной логике но каким образом там ссылки на инстанции классов которые являются периферии и значит находится на наружных слоях попадают в бизнес-логику если мы хотим что-нибудь сделать из бизнес-логики из там из кейсов из сервисов направо по штатам доступ например с
00:11:19 - 00:13:06
одного сервиса к другому как криптографический сервис какой-то и он ну это сервис сервис не касающейся доменной логике то есть он где-то на периферии находится а нам нужно к нему обращаться причем желательно так чтобы можно было его подменить в любой момент вот из бизнес-логики нам нужно что-то зашифровать но чтобы не не реализовывать это шифрование внутри и чтобы как можно меньше знал бизнес-логика о том как происходит шифрование ну если а там пришли к сервису который хорошо о своем остался в котором видим
00:12:15 - 00:13:54
прощаемся тонн большинстве случаев это будет реализованы при помощи микро сервисной архитектура когда мы будем отдельно сервер запрашивает но к нему делать запрос также можно запрашивать через очки запросам просто в таком случае нам надо будет реализовать ну какой то чтобы проверять можно ли брать ты когда-нибудь писал приложение или может быть читал какую-то литературу по чистой архитектуре клин архитектор смотри вот чтобы лучше понимать гексагональную я тебе с самого начала спросил из чего она вышла она на самом
00:13:05 - 00:14:48
деле вышло из слоеной архитектуры которая уже сто лет в общем исполнилось и одной из реализацией слоеная архитектура является вот чистая архитектура это как бы это условное название естественно потому что в принципе почти все что мы не возьмем все равно будет с военной архитектуры другой архитектуры кроме вот слоеной и pipeline сложно себе вообще представить на самом деле гексагональной это тоже какая-то реинкарнация слоеное ли чистые архитектуры просто в которой у нас очень четко определены там
00:13:58 - 00:15:31
порты и адаптеры и на самом деле ты говоришь что это сложная архитектура не для новичков тоже такой вот взгляд но мне кажется что наоборот гексагональной архитектуре очень много всего определено всяких рекомендаций всяких методологии всякой и ну очень сильно расписано из каких компонентов архитектура состоит в в слоеной ну просто говорится что вот нужно писать свои так чтобы они были изолированы как меньше как можно меньше перемешивали а из каких компонентов и какими способами там вот ну инверсии
00:14:44 - 00:16:11
управления там это значит как зависимости внедряются или как там допустим происходит обмен данными или там нужны ли адаптер и там или там значит когда мы через вызовы и интегрируем ся когда мы через событие но не не ничего не сказано об этом то есть выбирайте те способы какие хотите а если начать с чистой архитектуры и все почитать книжечки из которых это все вышло мне кажется что откроются ну основные идеи которые за всем этим лежат и вообще так конечно же гексагональной архитектура она для новичка проще потому что более
00:15:27 - 00:16:57
понятно все более расписано конечно же ну ты наверно сравнивал с тем как писать вообще без архитектуры понятное дело что с хоть какой-то архитектурой писать но это сложнее и это для более продвинутых людей но гексагональной специально вот так вот разжевывает все и дает шаблоны практически для всех частей приложения чтобы в общем человеку меньше было задумываться когда он начинает что-то писать это такая вот рекомендация посмотреть в сторону чистые архитектуры и слоеной архитектуры еще чтобы лучше
00:16:12 - 00:17:31
понимать гексагональную если уж ты ее использую сейчас проектах это так лекции по этому есть я сказал сложный потому что большинство из начинаю щитом абатура немножко могут трудностям они расписаны вот как сказали что там делай что хочешь и данные которые приходят и которые нужно брать может быть очень сложно распарсить ну вот собственно да начинающему проще всего писать без архитектуры просто начали пить все как попало и не думать про зацепление связанность там еще все вот эти вот аспекты и не разделять свои ну
00:16:52 - 00:18:19
как так но это просто дикое программирование без без архитектурная ну конечно она проще чтоб код писать но поддерживать такую систему это вообще полный от ну и может быть ты еще расскажешь про фронт и я так понимаю что это у вас тоже на фронте используются реакций и возможность серверами в гексагональной архитектуре вот скажем так как он вписывается во всю эту систему и можно ли вообще где-то в гексагональной архитектуре разместить где место пользовательских интерфейсов и вообще значит может быть там франта или
00:17:36 - 00:19:15
там значит вы оба реактор на четыре трубки то angular а или веб-компонентов так ну в общем всего вот это вот небо сам фронтом будет размещен за границами нашего шестигранника потому что как мне рассказали как закон архитектурой на сессии draw me to бизнес-логика и нынешний слоя характер и поэтому мы не должно быть связано с [музыка] бизнес-логика и вот мое предпочтение это создать им отдельный сервер просто который будет хиндли то я уже оттуда будет ссылаться запрос сама проекта через адаптер в каком-то реактор скам приложение там
00:18:25 - 00:20:07
же может быть часть бизнес-логики написан вообще как бы она свойственна только для клиентского приложения она там не серверная логика вот что получается нам нужно еще одну еще одно приложение отдельные тоже по гексагональной архитектуре или по какой-то другой архитектуре еще одно приложение делать на фронте и просто связывать одно приложение с другим или или как вот или она все-таки как-то вписывается ну то есть если нужно допустим что-то вычислять или часть бизнес-логики исполнять на фронте вот как тут быть
00:19:25 - 00:20:55
использованы красных архитектура и создал бы просто решили сервис которому бы обращался с manta для того чтобы вычислить некоторые данные и сказали поборы в нашем внедрение можно будет нет смотри я имею в виду что у нас есть пользовательский интерфейс и в пользовательском интерфейсе вот часть логике она может повторяться с той логикой которая допустим на сервере находится примерно вот допустим электронные таблицы вот мы делаем себе приложение для электронных таблиц у нас есть какой то значит движок для
00:20:13 - 00:21:37
вычисления реактивных вот этих ячеек с экспресс и нами на сервере и мы к нему присылаем данные собственно когда ищейка там меняется и все это может работать на сервере но при этом гонять все все время как только мы поменяли ячейку между сервером и клиентом не очень хотелось бы мы хотели бы все вот это дело еще для упрощения просто запускать на клиентской части ну конечно как только ячейка поменялось мы ее отправляем на сервер но все вычисления мы хотим обсчитать то клиенте ну это получается некоторое дублирование то есть
00:20:55 - 00:22:17
получается бизнес логика у нас два раза реализовано или как если это какой-то малая часть кода тогда думаю не будет ничего страшно если мы повторим то есть там два три файла как бы спрятать а если вы не хотим не хотим повторять какие у нас есть выходы и может быть что-то у тебя встречалась в работе такое что вот дублируется между сервером и клиентом таком случае у нас на наш проект должен будет отсылать юань и ну просто без адаптера будем тогда стоять переданы ну ну это может быть ты тогда расскажешь
00:21:36 - 00:23:03
каким образом из реактора мы осуществляем доступ к данным зачем нам нужны менеджеры состояния как можно обойтись без них и вот как это все может быть связано в одном приложении с реакторов целям и гексагональные сервером совсем понял вопрос как это все можно увязать все эти компоненты в один проект фронт на reactie менеджеры состояний возможно граф кель и сервер backend гексагональной в таком случае я думаю нам фронт для фонтан надо бы это какой-то мега сервис история отдельный сервис который будет
00:22:27 - 00:24:12
отсылать лайку оттуда у нас будет идти игра в теле запроса на какой-то 1point от даже может быть адаптер продать своего рода и сервис получится а потом не совсем прикольно вот так но если все же адаптер тогда тут просто с адаптером и будем ведь в бизнес-логику если же адаптер тогда этого наша it service on point будет запрос уже наш бизнес лодке через адаптер для меня об этом представления фронт будет как отдельный такой пучок от шестигранника который будет через что-то по 1 ok какие могут быть
00:23:20 - 00:25:09
оптимизацией чтобы мы снизили количество запросов и вообще обменов данными между фронтэнда и сервером ну может быть такую знаешь проблему n + 1 проблема как мы знаем у покрыли проблему на сумму нарушается кашин право не случай когда много там пользователи часто данные меняется тогда как нам не сильно поможет но можно кешировать были на серверном уровне чтобы время запроса было меньше ну в общем давай уже подытожим все это дело смотри у тебя явно есть широкий опыт и знания но только в той сфере который
00:24:17 - 00:26:09
касается конкретно ваших в общем архитектурных решений которые в проектах используются для того чтобы это как-то расширить и осознать место всех этих архитектурных решений вообще в принципе в во всем многообразии того что у нас имеется инструментария и вообще технологии то мне кажется что нужно во-первых подсчитать книжечек по всем этим вещам ну то есть ты сейчас учишь все из практики и вряд ли открываешь статьи по каким-то смежным или совсем не похожим технологиям она на самом деле полезно чтобы понимать какие есть альтернативы
00:25:12 - 00:26:56
ну и мне кажется что нужно еще побольше смотреть докладов на конференциях потому что ну на самом деле мы все самое новое мы даже не из книжек узнаем о узнаем из того что вот кто-то в каком-то проекте другом там не нашим или значит где-то кто-то значит что-то изобрел или же переосмыслил или же значит появилась какая-то новый подход и сначала появляется доклад потом появляется статье и только потом появляются книжки уже через там какое-то количество лет но конечно нужно вот на все эти три вещи тоже уделять время то есть доклады
00:26:05 - 00:27:50
статьи и книжки чтобы иметь широкий кругозор в всем инструментарий и все многообразие технологии ну где-то так так что а ну еще в общем ты иногда когда объясняешь ну чувствуется что ты понимаешь но при этом высказать словами это у тебя тяжко выходит поэтому мне кажется что нужно тренироваться объяснять возможно вы в коллективе мало взаимодействуете мало или может быть ты значит на в коллективе всегда есть какие то люди которые больше говорят да вот и наверное больше слушаешь мне кажется что нужно может быть завести вам в
00:26:56 - 00:28:44
коллективе такое обыкновение иногда делать внутренние какие-то этапы и объяснять значит тут кто-то узнал что-то новое и там на 20-30 минут объяснил всем остальным ну так будет развиваться навык того что выражение собственно понятными словами концепции идей которые где-то почерпнули и так будет гораздо проще потом разговаривать даже о тех технологиях которые вы внутри используете это просто совет ну понял специально
00:27:50 - 00:29:04