Я не знаю что для вас является швом. Человек писал что низачто не поверит, я указал на путь который сам использую в боевом проекте. Справедливости ради, в этом моменте изначальный вопрос с "как?" Перешёл на "зачем?".
По поводу примеров - за вас никто не напишет хороший и бесшовный код, не по ссылке, не в книжке, пишите его сами.
Так оно применяется в других случаях, не в тех, что описаны в статье, когда надо данные информационной системы где-то хранить и для доступа к этим данным нужно 1000 функций.
Почему вы мне все пытаетесь рассказать где применяется то чего вы даже не знали? И что это за 1000 функций? Вы каждый отдельный sql запрос оборачиваете в функцию?
Статья про Golang написана, там это называется "interface", https://go.dev/tour/methods/9
В го паттерн мост это интерфейс?
В статье написано, что при плохой структуре кода замена базы потребует 200 изменений в коде, а при хорошей - 10. Далее идет картинка Гибкость замены компонентов, на которой нарисовано, как PostgreSQL меняется на MongoDB. И это я хочу оспорить.
Техническое и информационная часть статьи оставляет желать лучшего впринципе.
но если данные сложные, то скорее всего вместо PostgreSQL потребудется поддержать другую реляционную СУБД
Подскажите, а что за "сложные данные" не поддерживаются постгресом?
Это будет делаться исключетельно по просьбе крупного клиента за большие деньги
Вот вам ещё 1 пример где это можно использовать, продавать продукт где то, что вы хотите продать за большие деньги идет из коробки.
Либо будет доступ к базе через ORM, либо будет базовая реализация 990 функций репозитория на стандартном SQL и различная реализация с оптимизациями и кастомными фичами Postgres и Oracle оставшихся 10 функций. Но все 1000 функций 2 раза писать - это жесть.
Да уж, с вашим статусом разработчика такой компании все это звучит... так себе, не чего личного.
И не обязательно реализовывать все фичи репозитория (я не понимаю это программный репозиторий или вы так базу данных называете). Можно реализовать скелет например sql и дальше его расширять и вытягивать какие угодно фичи с уже готовым скелетом
Как бы понятнее сказать, при правильной архитектуре вы точечно получаете функционал от бд который вам нужен, а вы про какие-то 1000 функций реализованных по 2 раза
Я имею ввиду в реальном проекте, а не в примере TodoList из книжки.
Вы сейчас называете опыт программистов накопленный десятилетиями просто каким-то развлечением? Или вы не знаете как примеры из книжки применять на реальные проекты?
В реальном проекте он может и не понадобиться, а может и понадобиться (санкции? Пожелание заказчика? Ещё что-то?). И темболее сначала вы говорили что просто не верите, теперь вот не верите, а если поверите оно и не нужно вообще.
Да, есть, конечно, примеры, когда ваш паттерн "мост" необходимо использовать, но это точно не реализация основного репозитория.
Ну и, вот так сходу, принижать то чего вы даже не знали, как-то так себе.
Вы представляете репозиторий как любой доступ к базе или что? Помоему репозиторий это обёртка в которой данные пришедшие от бд преобразуются во внутренний программный объект?
То есть не делают несколько реализаций одного интерфейса
А для чего ещё интерфейсы нужны, если не реализовывать их? Чтобы всем рассказывать что у нас DDD? Или чистая архитектура...
А почему у вас бизнес логика в инфраструктурном слое?
Если честно хотелось покопаться в структуре кода, но пока пытался из этой каши приведённых вами кусков расположения папок что-то понять, уже как-то и перехотелось.
Согласен, там в углу DDD пэинтом нарисовано, но в DDD инверсия зависимостей идёт изнутри внаружу, от домена, а не просто домен рядом с инфраструктурой(???)
Как-то быстро оборвалась статья только я начал погружаться.
Гексогональная архитектура это круто!
Но зачем вы порты вместо стандартных левых и правых называете ведомый и ведущий? А во вторых на картинке вы показываете как домен обращается через порты к базам данных, что крайне не верно! О чем вы сами в начале статье говорите как о плюсе чистой архитектуры, домен через порты не должен ходить в базу, он вообще просто должен принимать данные и отдавать
Подскажите, хотелось бы честно, вы использовали нейросети для построения архитектуры? (Возможно и статьи). Я просто как-то просил DeepSeek написать гексогональную архитектуру и было что-то похожее.
За многабукф статьи потерялся практический смысл полиморфизма
А у меня не потерялся, а даже приобрелся. Практический смысл зависит от вашего желания и опыта. То что я раньше городил просто страшно вспомнить, после ООП все встало на свои места. Код поддерживаемый и читаемый, а также логика жёстко ограничена правильным взаимодействием и тем самым отсутствием багов при большом количестве кода, да у этого есть минусы, например копирование кода, но представьте, мне даже у нейросети не надо код просить чтобы расширить приложение, клёво?
Как вам правильно подметили в комментариях, полиморфизм это не прерогатива ООП. Такое ощущение что вы думаете что когда пишешь на ООП, то ты пишешь не на языке программирования, а занимаешься непонятно чем.
Потратив несколько лет на очень изнуряющее обучение, ты стоишь и смотришь, как чуваки с улицы крутят себе опыт, и проходят на зарплаты в 2-3 раза больше твоей.
Уже были мысли что я один такой, какой-то не такой для всего этого. Хоть и не выпускник топ ВУЗа, но тоже думал что если получу образование это будет плюсом. Потом ещё по хаккатонам ездил, и даже в международном конкурсе победил, но на это никто не смотрит.
Хорошо, я загуглил, конвеер ЦПУ распараллеливает выполнение команд, и как это не бьётся с тем что если я зввершу процесс то они не будут выполняться даже в конвеере?))
Опять же вы пишите что закулиса недоступна программисту, но гугл пишет что программисты оптимизировали компиляторы под конвееры в ЦПУ... и кто из вас меня пытается надурить? :)
есть вилка и есть зубчики вилки
Зубчики могут существовать и без вилки, а вот СИНТАКСИЧЕСКИЙ сахар не может без языка, понимаете?))
Без гугла ответите чем агрегация отличается от композиции?)
Знаете, мне кажется тут как в искусстве, человеку не может нравиться то чего он не понимает.
Вы это как плюс приписываете?))
Я не знаю что для вас является швом. Человек писал что низачто не поверит, я указал на путь который сам использую в боевом проекте. Справедливости ради, в этом моменте изначальный вопрос с "как?" Перешёл на "зачем?".
По поводу примеров - за вас никто не напишет хороший и бесшовный код, не по ссылке, не в книжке, пишите его сами.
Почему вы мне все пытаетесь рассказать где применяется то чего вы даже не знали? И что это за 1000 функций? Вы каждый отдельный sql запрос оборачиваете в функцию?
В го паттерн мост это интерфейс?
Техническое и информационная часть статьи оставляет желать лучшего впринципе.
Подскажите, а что за "сложные данные" не поддерживаются постгресом?
Вот вам ещё 1 пример где это можно использовать, продавать продукт где то, что вы хотите продать за большие деньги идет из коробки.
Да уж, с вашим статусом разработчика такой компании все это звучит... так себе, не чего личного.
И не обязательно реализовывать все фичи репозитория (я не понимаю это программный репозиторий или вы так базу данных называете). Можно реализовать скелет например sql и дальше его расширять и вытягивать какие угодно фичи с уже готовым скелетом
Как бы понятнее сказать, при правильной архитектуре вы точечно получаете функционал от бд который вам нужен, а вы про какие-то 1000 функций реализованных по 2 раза
???? Это вообще без комментариев
Вы сейчас называете опыт программистов накопленный десятилетиями просто каким-то развлечением? Или вы не знаете как примеры из книжки применять на реальные проекты?
В реальном проекте он может и не понадобиться, а может и понадобиться (санкции? Пожелание заказчика? Ещё что-то?). И темболее сначала вы говорили что просто не верите, теперь вот не верите, а если поверите оно и не нужно вообще.
Ну и, вот так сходу, принижать то чего вы даже не знали, как-то так себе.
Вы представляете репозиторий как любой доступ к базе или что? Помоему репозиторий это обёртка в которой данные пришедшие от бд преобразуются во внутренний программный объект?
А для чего ещё интерфейсы нужны, если не реализовывать их? Чтобы всем рассказывать что у нас DDD? Или чистая архитектура...
А почему у вас бизнес логика в инфраструктурном слое?
Если честно хотелось покопаться в структуре кода, но пока пытался из этой каши приведённых вами кусков расположения папок что-то понять, уже как-то и перехотелось.
Меня больше рассмешило что автор предлагает "самых интересных" комментаторов в статью добавить)))
DDD чётко прописывает инверсию зависимостей вашей архитектуры. По сути любая программа имеет архитектуру, вопрос в том хорошую или плохую.
Приведите пример конкретный, и что за приёмы? Это паттерны?
Читать другую статью
Если честно и примеры кода и статья наталкивает на мысль что да)
Согласен, там в углу DDD пэинтом нарисовано, но в DDD инверсия зависимостей идёт изнутри внаружу, от домена, а не просто домен рядом с инфраструктурой(???)
Картинка эта неправильна
Получается вы мне не поверите если я скажу что можно это сделать паттерном мост?
(Вы работаете в ВК программистом? Даже руководитель комманды. Извините, у меня аж дыхание чучуть перехватило)
Как-то быстро оборвалась статья только я начал погружаться.
Гексогональная архитектура это круто!
Но зачем вы порты вместо стандартных левых и правых называете ведомый и ведущий? А во вторых на картинке вы показываете как домен обращается через порты к базам данных, что крайне не верно! О чем вы сами в начале статье говорите как о плюсе чистой архитектуры, домен через порты не должен ходить в базу, он вообще просто должен принимать данные и отдавать
Подскажите, хотелось бы честно, вы использовали нейросети для построения архитектуры? (Возможно и статьи). Я просто как-то просил DeepSeek написать гексогональную архитектуру и было что-то похожее.
А у меня не потерялся, а даже приобрелся. Практический смысл зависит от вашего желания и опыта. То что я раньше городил просто страшно вспомнить, после ООП все встало на свои места. Код поддерживаемый и читаемый, а также логика жёстко ограничена правильным взаимодействием и тем самым отсутствием багов при большом количестве кода, да у этого есть минусы, например копирование кода, но представьте, мне даже у нейросети не надо код просить чтобы расширить приложение, клёво?
Как вам правильно подметили в комментариях, полиморфизм это не прерогатива ООП. Такое ощущение что вы думаете что когда пишешь на ООП, то ты пишешь не на языке программирования, а занимаешься непонятно чем.
P.S. Что у вас за нейросетевой штурм какой-то?)
Уже были мысли что я один такой, какой-то не такой для всего этого. Хоть и не выпускник топ ВУЗа, но тоже думал что если получу образование это будет плюсом. Потом ещё по хаккатонам ездил, и даже в международном конкурсе победил, но на это никто не смотрит.
Когда дают веник и говорят сыграй, надо вернуть и сказать настрой))
Хорошо, я загуглил, конвеер ЦПУ распараллеливает выполнение команд, и как это не бьётся с тем что если я зввершу процесс то они не будут выполняться даже в конвеере?))
Опять же вы пишите что закулиса недоступна программисту, но гугл пишет что программисты оптимизировали компиляторы под конвееры в ЦПУ... и кто из вас меня пытается надурить? :)
Зубчики могут существовать и без вилки, а вот СИНТАКСИЧЕСКИЙ сахар не может без языка, понимаете?))
Без гугла ответите чем агрегация отличается от композиции?)
А до ИИ гипотез не существовало? Я бы вам рекомендовал не верить слепо в чёрный ящик под названием ИИ
У стартаперов эго сильно большое, по всей видимости :)