Вайб кодинг это классно, стильно, модно, современно. Но, судя по своему опыту, сухая реализация это даже не половина того что должен уметь делать программист. Сверстать лендинг, хуже чем сейчас конечно, но более менее красивый я мог уже на 2 курсе учебы. Я к тому что именно научиться писать код и даже что-то "рабочее" реализовать не так уж и сложно при должном желании. Дальше уже встают вопросы посерьезнее - масштабирование, жизненный цикл приложения, внутренняя работа языков и так далее (очень далее).
Надо ещё уточнить что есть не только паттерны, но и антипатерны, например DRISTAL, или известная в простонародье как стрельба дробью. Код как бы размазывается по проекту
Да, я согласен что есть хорошие места, чисто потому что думаю что не может быть у всех одинаково плохо) Но тут опять встаёт вопрос найма, так сказать с внешней стороны сейчас найм прогеров в ИТ выглядит плюс минус у всех одинаково, я думаю это тоже может говорить о похожесте внутренних проблем компании. Как вы писали в статье, людям сложно отказываться(переосмыслять) от решений которые придумали до них и активно используются
Прочитал статью на одном дыхании, просто не мог остановиться, я раньше стремился в большие компании, думал что там круто, но после работы в них я вынес оттуда много негатива и недоумения в частности работы бизнеса и сотрудников. Вы мне открыли глаза на то что все же люди это просто люди, хоть топ директора, хоть обычный прохожий на улице. И про найм интересно прочитать было, я пока точил свои технические навыки, так и не научился продавать себя...
Мне кажется что деньги текут туда, где быстрее видно результат, например во фронтенд. Да и почему столько плюсов у статьи, когда минусуется ответ автора на смысл статьи?)) Вам из функций собрали объекты и дали строгую логику, развивайте эту мысль дальше
Ваш слон выглядит странно и некоторые вещи очень очевидны. Да и в чем тут тупик? Может про ООП так много говорят, потому что его насаждали в языках (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.
Вы продолжаете реально топить что интерфейс сам по себе в го добавляет какой-то гибкости? И кто, кроме может автора статьи, вообще говорит что само по себе использование интерфейса что-то вообще даёт? Я вам привёл пример паттерна мост, чистый, самый простой интерфейс сам по себе не имеет никакого отношения к этому.
Вайб кодинг это классно, стильно, модно, современно. Но, судя по своему опыту, сухая реализация это даже не половина того что должен уметь делать программист. Сверстать лендинг, хуже чем сейчас конечно, но более менее красивый я мог уже на 2 курсе учебы. Я к тому что именно научиться писать код и даже что-то "рабочее" реализовать не так уж и сложно при должном желании. Дальше уже встают вопросы посерьезнее - масштабирование, жизненный цикл приложения, внутренняя работа языков и так далее (очень далее).
Надо ещё уточнить что есть не только паттерны, но и антипатерны, например DRISTAL, или известная в простонародье как стрельба дробью. Код как бы размазывается по проекту
Да
Да, я согласен что есть хорошие места, чисто потому что думаю что не может быть у всех одинаково плохо) Но тут опять встаёт вопрос найма, так сказать с внешней стороны сейчас найм прогеров в ИТ выглядит плюс минус у всех одинаково, я думаю это тоже может говорить о похожесте внутренних проблем компании. Как вы писали в статье, людям сложно отказываться(переосмыслять) от решений которые придумали до них и активно используются
Прочитал статью на одном дыхании, просто не мог остановиться, я раньше стремился в большие компании, думал что там круто, но после работы в них я вынес оттуда много негатива и недоумения в частности работы бизнеса и сотрудников. Вы мне открыли глаза на то что все же люди это просто люди, хоть топ директора, хоть обычный прохожий на улице. И про найм интересно прочитать было, я пока точил свои технические навыки, так и не научился продавать себя...
Мне кажется что деньги текут туда, где быстрее видно результат, например во фронтенд. Да и почему столько плюсов у статьи, когда минусуется ответ автора на смысл статьи?)) Вам из функций собрали объекты и дали строгую логику, развивайте эту мысль дальше
Это аксиома необходимая в доказательствах и развитии мысли. А не просто что он открыл прямую линию)
Ваш слон выглядит странно и некоторые вещи очень очевидны. Да и в чем тут тупик? Может про ООП так много говорят, потому что его насаждали в языках (Java, c#) Я например нахожу его очень удобным и совсем не тупиковым, если вы про это.
Еще и на картинке тоже показываете
У вас "стрелочки" из домена идут внаружу только для общих пакетов, что вы сами и пишите:
И причем тут CORS? У вас реализация корс в каком-то отдельном пакете? Чем глубже читаешь, тем больше понимаешь что лайки заслужены конечно)
Просто Go и микросервис это круто, а PHP и монолит это отстой.
ОП ОП ООП Народ! Хотите прикол? Фасад?
Я маленько углубился, и вы похоже пытаетесь сделать (или просто аппелируете к этим понятиям) CQRS, который основан на CQS, для которого есть специальный язык заточенный под эту парадигму.
Ну и стрелку я отчетливо вижу) Нет?
Большая статья, но если коротко, почему вы вначале рисуете зависимости снаружи во внутрь? Почему домену нельзя пользоваться своей же оберткой? Для чего вообще тогда слои? CQS, на сколько я понимаю относится к методам класса, а не архитектуре приложения, и вы, по всей видимости, путаете его с паттерном ООП команда. И почему у людей в гексогональной архитектуре порты только в 1 месте всегда? А слои как между собой общаются?
Хорошо бы всем понимать как работают строки в языке которым они пользуются :) В go просто строгая типизация и по этому такие вещи приходится учитывать.
Интерфейс это контракт с уже существующей логикой программы при расширении функционала
Своим видом через 5 лет. Онбордингом, способом расширения архитектуры (клиентским кодом), где интерфейс это осознанная точка роста, а не просто реализация из книжки которая познается на 5ый день обучения, как вы говорили ранее, 1 интерфейс 5ть реализаций, это не гибкость а микросервис какой-то.
Под гибкостью я понимаю гибкость архитектуры, а не гибкость, которая появляется за счет того что у нас 1 интерфейс и 3, 4, 5, n реализаций...
Вы продолжаете реально топить что интерфейс сам по себе в го добавляет какой-то гибкости? И кто, кроме может автора статьи, вообще говорит что само по себе использование интерфейса что-то вообще даёт? Я вам привёл пример паттерна мост, чистый, самый простой интерфейс сам по себе не имеет никакого отношения к этому.