Да, я согласен что есть хорошие места, чисто потому что думаю что не может быть у всех одинаково плохо) Но тут опять встаёт вопрос найма, так сказать с внешней стороны сейчас найм прогеров в ИТ выглядит плюс минус у всех одинаково, я думаю это тоже может говорить о похожесте внутренних проблем компании. Как вы писали в статье, людям сложно отказываться(переосмыслять) от решений которые придумали до них и активно используются
Прочитал статью на одном дыхании, просто не мог остановиться, я раньше стремился в большие компании, думал что там круто, но после работы в них я вынес оттуда много негатива и недоумения в частности работы бизнеса и сотрудников. Вы мне открыли глаза на то что все же люди это просто люди, хоть топ директора, хоть обычный прохожий на улице. И про найм интересно прочитать было, я пока точил свои технические навыки, так и не научился продавать себя...
Мне кажется что деньги текут туда, где быстрее видно результат, например во фронтенд. Да и почему столько плюсов у статьи, когда минусуется ответ автора на смысл статьи?)) Вам из функций собрали объекты и дали строгую логику, развивайте эту мысль дальше
Ваш слон выглядит странно и некоторые вещи очень очевидны. Да и в чем тут тупик? Может про ООП так много говорят, потому что его насаждали в языках (Java, c#) Я например нахожу его очень удобным и совсем не тупиковым, если вы про это.
У вас "стрелочки" из домена идут внаружу только для общих пакетов, что вы сами и пишите:
В пакете internal/shared можно хранить, например, строковые константы, используемые во всех слоях или единый перечень ошибок (var Err...), используемых повсеместно в приложении:
internal/shared/strconst
internal/shared/errors
В internal/pkg можно поместить middleware fiber с вашей собственной реализацией CORS. Напротив, если в middleware fiber обрабатываются ошибки из пакета internal/domain, то такой код нужно оставить в слое инфраструктуры. В демо-приложении в internal/pkg размещен пакет pgxtx, который отвечает за передачу транзакции БД в context.Context. Однако содержимое pgxtx можно было бы оставить и в слое инфраструктуры, поскольку эта функциональность используется только там.
И причем тут CORS? У вас реализация корс в каком-то отдельном пакете? Чем глубже читаешь, тем больше понимаешь что лайки заслужены конечно)
Я маленько углубился, и вы похоже пытаетесь сделать (или просто аппелируете к этим понятиям) CQRS, который основан на CQS, для которого есть специальный язык заточенный под эту парадигму.
Большая статья, но если коротко, почему вы вначале рисуете зависимости снаружи во внутрь? Почему домену нельзя пользоваться своей же оберткой? Для чего вообще тогда слои? CQS, на сколько я понимаю относится к методам класса, а не архитектуре приложения, и вы, по всей видимости, путаете его с паттерном ООП команда. И почему у людей в гексогональной архитектуре порты только в 1 месте всегда? А слои как между собой общаются?
Хорошо бы всем понимать как работают строки в языке которым они пользуются :) В go просто строгая типизация и по этому такие вещи приходится учитывать.
Своим видом через 5 лет. Онбордингом, способом расширения архитектуры (клиентским кодом), где интерфейс это осознанная точка роста, а не просто реализация из книжки которая познается на 5ый день обучения, как вы говорили ранее, 1 интерфейс 5ть реализаций, это не гибкость а микросервис какой-то.
В C и ассемблере это указатели на функции (и структуры с набором указателей на функции), в C++ - наследование и виртуальные функции, в Java и Go - интерфейсы. Я не понимаю, зачем этот подход преподносить как какую-то чудесную хитрость чистой архитектуры от дядюшки Боба, это используется уже лет 50 точно в программах чуть сложнее Hello world.
Вы продолжаете реально топить что интерфейс сам по себе в го добавляет какой-то гибкости? И кто, кроме может автора статьи, вообще говорит что само по себе использование интерфейса что-то вообще даёт? Я вам привёл пример паттерна мост, чистый, самый простой интерфейс сам по себе не имеет никакого отношения к этому.
Я не знаю что для вас является швом. Человек писал что низачто не поверит, я указал на путь который сам использую в боевом проекте. Справедливости ради, в этом моменте изначальный вопрос с "как?" Перешёл на "зачем?".
По поводу примеров - за вас никто не напишет хороший и бесшовный код, не по ссылке, не в книжке, пишите его сами.
Так оно применяется в других случаях, не в тех, что описаны в статье, когда надо данные информационной системы где-то хранить и для доступа к этим данным нужно 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 раза
Да, я согласен что есть хорошие места, чисто потому что думаю что не может быть у всех одинаково плохо) Но тут опять встаёт вопрос найма, так сказать с внешней стороны сейчас найм прогеров в ИТ выглядит плюс минус у всех одинаково, я думаю это тоже может говорить о похожесте внутренних проблем компании. Как вы писали в статье, людям сложно отказываться(переосмыслять) от решений которые придумали до них и активно используются
Прочитал статью на одном дыхании, просто не мог остановиться, я раньше стремился в большие компании, думал что там круто, но после работы в них я вынес оттуда много негатива и недоумения в частности работы бизнеса и сотрудников. Вы мне открыли глаза на то что все же люди это просто люди, хоть топ директора, хоть обычный прохожий на улице. И про найм интересно прочитать было, я пока точил свои технические навыки, так и не научился продавать себя...
Мне кажется что деньги текут туда, где быстрее видно результат, например во фронтенд. Да и почему столько плюсов у статьи, когда минусуется ответ автора на смысл статьи?)) Вам из функций собрали объекты и дали строгую логику, развивайте эту мысль дальше
Это аксиома необходимая в доказательствах и развитии мысли. А не просто что он открыл прямую линию)
Ваш слон выглядит странно и некоторые вещи очень очевидны. Да и в чем тут тупик? Может про ООП так много говорят, потому что его насаждали в языках (Java, c#) Я например нахожу его очень удобным и совсем не тупиковым, если вы про это.
Еще и на картинке тоже показываете
У вас "стрелочки" из домена идут внаружу только для общих пакетов, что вы сами и пишите:
И причем тут CORS? У вас реализация корс в каком-то отдельном пакете? Чем глубже читаешь, тем больше понимаешь что лайки заслужены конечно)
Просто Go и микросервис это круто, а PHP и монолит это отстой.
ОП ОП ООП Народ! Хотите прикол? Фасад?
Я маленько углубился, и вы похоже пытаетесь сделать (или просто аппелируете к этим понятиям) CQRS, который основан на CQS, для которого есть специальный язык заточенный под эту парадигму.
Ну и стрелку я отчетливо вижу) Нет?
Большая статья, но если коротко, почему вы вначале рисуете зависимости снаружи во внутрь? Почему домену нельзя пользоваться своей же оберткой? Для чего вообще тогда слои? CQS, на сколько я понимаю относится к методам класса, а не архитектуре приложения, и вы, по всей видимости, путаете его с паттерном ООП команда. И почему у людей в гексогональной архитектуре порты только в 1 месте всегда? А слои как между собой общаются?
Хорошо бы всем понимать как работают строки в языке которым они пользуются :) В go просто строгая типизация и по этому такие вещи приходится учитывать.
Интерфейс это контракт с уже существующей логикой программы при расширении функционала
Своим видом через 5 лет. Онбордингом, способом расширения архитектуры (клиентским кодом), где интерфейс это осознанная точка роста, а не просто реализация из книжки которая познается на 5ый день обучения, как вы говорили ранее, 1 интерфейс 5ть реализаций, это не гибкость а микросервис какой-то.
Под гибкостью я понимаю гибкость архитектуры, а не гибкость, которая появляется за счет того что у нас 1 интерфейс и 3, 4, 5, n реализаций...
Вы продолжаете реально топить что интерфейс сам по себе в го добавляет какой-то гибкости? И кто, кроме может автора статьи, вообще говорит что само по себе использование интерфейса что-то вообще даёт? Я вам привёл пример паттерна мост, чистый, самый простой интерфейс сам по себе не имеет никакого отношения к этому.
Знаете, мне кажется тут как в искусстве, человеку не может нравиться то чего он не понимает.
Вы это как плюс приписываете?))
Я не знаю что для вас является швом. Человек писал что низачто не поверит, я указал на путь который сам использую в боевом проекте. Справедливости ради, в этом моменте изначальный вопрос с "как?" Перешёл на "зачем?".
По поводу примеров - за вас никто не напишет хороший и бесшовный код, не по ссылке, не в книжке, пишите его сами.
Почему вы мне все пытаетесь рассказать где применяется то чего вы даже не знали? И что это за 1000 функций? Вы каждый отдельный sql запрос оборачиваете в функцию?
В го паттерн мост это интерфейс?
Техническое и информационная часть статьи оставляет желать лучшего впринципе.
Подскажите, а что за "сложные данные" не поддерживаются постгресом?
Вот вам ещё 1 пример где это можно использовать, продавать продукт где то, что вы хотите продать за большие деньги идет из коробки.
Да уж, с вашим статусом разработчика такой компании все это звучит... так себе, не чего личного.
И не обязательно реализовывать все фичи репозитория (я не понимаю это программный репозиторий или вы так базу данных называете). Можно реализовать скелет например sql и дальше его расширять и вытягивать какие угодно фичи с уже готовым скелетом
Как бы понятнее сказать, при правильной архитектуре вы точечно получаете функционал от бд который вам нужен, а вы про какие-то 1000 функций реализованных по 2 раза