Так и говорим - нужна третья сущность, которая знает про обе модели

мне даже сложно подобрать название такой сущности

ну такое

Норм, норм. Тебе пакетов что ли жалко?

Слой работы с хттп (объекты А, конвертеры А-В, работа с протоколом) Слой бизнес логики (бизнес логика, объекты В) Слой работы с БД (объекты Б, конвертера Б-В, клиент БД)

кроме всякие utils

Конвертер

Если я не наврал, конечно

Сервис

кроме всякие utils

и чем utils/convert.go плохо?

Дата трансформер

You name it

кроме всякие utils

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

Ор

обсуждать нейминг пакетов и куда положить код это вообще проблема первого мира

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

удачи вам

обсуждать нейминг пакетов и куда положить код это вообще проблема первого мира

Джуниоров что ли?

Дата трансформер

Плюсану. Назови пакет dto и будет норм

а не ерись "one-man-army"

от суда и все сложности

ибо нет промышленных стандартов

Лучше полные имена для переменных и классов

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

всем насрать на твой код, даже тому, кто будет поддерживать

ты придумал проблему из создуха

да и если что-то не так, в нормальной IDE перенести файл из одного пакета в другой -- 30 секунд

а ты эту рпоблему обсуждаешь уже минут 5

всем насрать на твой код, даже тому, кто будет поддерживать

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

Это реально бред, чувак

я все пытаюсь добиться "самодокументирования"

а ты эту рпоблему обсуждаешь уже минут 5

"Ну чо ты сразу, нормально же общались" (с)

Потрындеть это святое

да это странные приоритеты, код пиши, после того как напишешь -- подумаешь

перенести код из одного пакета в другой -- реально дешево

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

и всегда можно сделать

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

ага, потом сядешь на антидепрессанты и прыгнешь под поезд, кек

удачи вам всем, пошел работать ?

мне реально уже надо садится на антидепрессанты

я даже в выходные не могу расслабиьтся

все думаю думаю как же лучше оформить

я даже в выходные не могу расслабиьтся

Рекомендую отпуск и смену работы

мог бы я это быстро решить? конечною

http://golangshow.com/episode/2018/10-03-127-en/

Рекомендую отпуск и смену работы

я был в отпуске, формально месяц, но реально дней 5

слишком сроки жмут и меня тупо некем подменить

Реально 2 недели надо. иначе не отпустит

слишком сроки жмут и меня тупо некем подменить

Сходи попроси денег. Самое время, лол.

Сходи попроси денег. Самое время, лол.

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

Это сейчас, а потом состояние пройдёт, а деньги останутся

Тоже по опыту говорю

utils.FromHttpModelToDB(httpmodelusers) dbusers O_o

но я вот чую, что пиздец он где то рядом

Нейминг не огонь

варианты есть?

HttpToDB ?

учитывая что надо на каждую модель так сделать

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

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

В общем, не хотел бы я поддерживать эти сервисы.

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

А вот то, что ты описал - смахивает на невроз небольшой

Или ОКР

Короче переоцениваешь проблему. Работа лишь работа

utils.FromHttpModelToDB(httpmodelusers) dbusers O_o

Я конечно не знаю что там за задача, но трансформация из модели хттп в модель дб сама по себе настораживает. Если бы была внутренняя модель, то преобразования были бы в пакетах дб и хттп соответственно, и выглядели бы они примерно как db.UserToModel/db.UserFromModel или както так.

Это все если следовать clean architecture

Твоей семье лучше, чтобы ты не сломался к 40

Сходи попроси денег. Самое время, лол.

Два чаю этому господину.

Окр по сообщению в чате ставить - это сильно

Я конечно не знаю что там за задача, но трансформация из модели хттп в модель дб сама по себе настораживает. Если бы была внутренняя модель, то преобразования были бы в пакетах дб и хттп соответственно, и выглядели бы они примерно как db.UserToModel/db.UserFromModel или както так.

ну тут рекомендации видишь от товарищей сделать промежуточный слой

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

Я конечно не знаю что там за задача, но трансформация из модели хттп в модель дб сама по себе настораживает. Если бы была внутренняя модель, то преобразования были бы в пакетах дб и хттп соответственно, и выглядели бы они примерно как db.UserToModel/db.UserFromModel или както так.

+1

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

Окр по сообщению в чате ставить - это сильно

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

По симптомам подходит, кек.

Сходи попроси денег. Самое время, лол.

Да там жопа вроде с этим сейчас. Ему так-то наверное надо вакансии смотреть. Наверняка есть удаленки, где рвения оценят

Да там жопа вроде с этим сейчас. Ему так-то наверное надо вакансии смотреть. Наверняка есть удаленки, где рвения оценят

Ну ему либо дадут, либо он может уйти.

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

Почитай про clean architecture

читал

несколько раз

очень сложно "нацепить" эту идеальную модель на реальные бизнес кейсы

Совершенно верно, пойдет работать дворником.

нет естественно, пойдёт туда где и платят лучше, и работать интереснее

Теоретические идеи задротов вообще сложно на глобус натягивать

Теоретические идеи задротов вообще сложно на глобус натягивать

> pook

нет естественно, пойдёт туда где и платят лучше, и работать интереснее

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

Теоретические идеи задротов вообще сложно на глобус натягивать

порвался неосилятор

очень сложно "нацепить" эту идеальную модель на реальные бизнес кейсы

Если сложно всю натянуть, то возьми часть

порвался неосилятор

Я то тереблю на архитектуру. Но мне милее п2п

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

Да я когда в чате вопросы по архитектуре задаю, так же себя веду

Если сложно всю натянуть, то возьми часть

да не реально, слишком простые модели в примере

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

сложные какие-то шутки

мне бы хоть одним глазком посмотреть как это сделано в "кашерных" проектах, хотя бы на 100 000 строк

бизнесовых в смысле

очень сложно "нацепить" эту идеальную модель на реальные бизнес кейсы

https://github.com/sidh/clean-architecture Маленький пример "нацеппления". Не самый лучший, но думаю подойдет

да не реально, слишком простые модели в примере

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

Да я когда в чате вопросы по архитектуре задаю, так же себя веду

стоимость неправильной архитектуры кажется на несколько порядков больше, чем стоимость названия пакета (30 секунд)

стоимость неправильной архитектуры кажется на несколько порядков больше, чем стоимость названия пакета (30 секунд)

Плохое название пакета потом годами бесит

сложные какие-то шутки

ну чтобы у него не было отвественности за именования и болей