потому, что автор - это автор, пользователь - это пользователь они могут совпадать, а могут не совпадать

иди делами займись. это реально бесполезно. Тут горутины и микросервисы с mvc

иди делами займись. это реально бесполезно. Тут горутины и микросервисы с mvc

реализую последний шанс

вот тебе и все разделение контекстов

Дайте я про это почитаю. Самое главное — зачем оно надо.

Всегда есть фанатичные евангелисты чудо методологии, спорить с ними нет смысла, поэтому когда они уходят работать это хорошо

тебе глубоко плевать на то, какой пользователь написал книгу или статью, если твой контекст оперирует понятием "автор"

Что в обсуждаемой теме сложно? 50% "сложности" создание оптимальной продуманной структуры базы данных, все остальное уходит на обвес к ней

Дайте я про это почитаю. Самое главное — зачем оно надо.

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

Дайте я про это почитаю. Самое главное — зачем оно надо.

отчасти для того, чтобы разные люди могли работать на проекте и не пересекаться. С любовью, ваш к.о. это как причина, за которую вы изначально вещали :)

Всегда есть фанатичные евангелисты чудо методологии, спорить с ними нет смысла, поэтому когда они уходят работать это хорошо

не считаю себя фанатичным евангелистом от слова совсем :) но в противовес этому не идёт банальное невежество.

Нет, ну а что мне мешает сделать id автора = id пользователя, и при этом люди всё равно не будут пересекаться. Меня больше интересует, как это будет выглядеть на уровне БД: отдельная таблица с авторами, что ли?

не считаю себя фанатичным евангелистом от слова совсем :) но в противовес этому не идёт банальное невежество.

Однако общаешься именно так, как знаток единственно верного подхода среди недоучек

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

Вон Вернон «Реализация методов предметно-ориентированного проектирования»?

Однако общаешься именно так, как знаток единственно верного подхода среди недоучек

не единственно верного, а ещё одного. Так будет точнее

Вон Вернон «Реализация методов предметно-ориентированного проектирования»?

да

Ну я про DDD доклад на конфе смотрел и так и не понял, отличается ли оно вообще чем-то.

Ну я про DDD доклад на конфе смотрел и так и не понял, отличается ли оно вообще чем-то.

"оно" - ddd? от чего?

более того, чтобы вникнуть в DDD - одного доклада не хватит

Ну я про DDD доклад на конфе смотрел и так и не понял, отличается ли оно вообще чем-то.

ddd - про общение с бизнесом, а не про код и структуру

а контексты относятся в том числе к общению с бизнесом

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

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

Ну, там точно такие же сущности же (а доклад ещё и на Java-конференции был): Статья, Автор, их методы...

Там разбирались какие-то отличия, конечно, но...

Ну, там точно такие же сущности же (а доклад ещё и на Java-конференции был): Статья, Автор, их методы...

это следствие, а не причина. Объяснить ddd на примере банально не получится. Ровно как и построить идеальный мир по всем канонам

не единственно верного, а ещё одного. Так будет точнее

Точнее будет одного из многих работающих, но стиль общения у тебя странный да. Еще есть такая мысль что если не можешь простыми словами что то объяснить так чтобы другие поняли, то скорее всего от того что сам недостаточно хорошо понял. Я знаю о чем ты, но по вопросам и твоим ответам на них не видно чтобы ты пытался хоть что то пояснить Так что лучшее решение пойти поработать

Точнее будет одного из многих работающих, но стиль общения у тебя странный да. Еще есть такая мысль что если не можешь простыми словами что то объяснить так чтобы другие поняли, то скорее всего от того что сам недостаточно хорошо понял. Я знаю о чем ты, но по вопросам и твоим ответам на них не видно чтобы ты пытался хоть что то пояснить Так что лучшее решение пойти поработать

куда уж мне :)

объяснить всё это простыми словами могут только продавцы mvc, scrum, ddd и прочих хайповых денежных конференций. только к объяснениям это не относится и цель преследует иную :)

объяснить всё это простыми словами могут только продавцы mvc, scrum, ddd и прочих хайповых денежных конференций. только к объяснениям это не относится и цель преследует иную :)

Ладно, тогда ответьте на простой вопрос: почему id автора должно отличаться от id пользователя?

Ладно, тогда ответьте на простой вопрос: почему id автора должно отличаться от id пользователя?

не должно, а может

Ладно, тогда ответьте на простой вопрос: почему id автора должно отличаться от id пользователя?

само значение может быть одинаково. Но это абсолютно разные вещи.

если удобно, представь, что это разные типы данных.

это разные контексты. в однмо контексте автор, в другом юзер. разные сущности.

Окей, ладно, есть отдельно автор и отдельно юзеры. Тогда выборка всех статей автора будет происходить исключительно средствами модуля со статьями, логично же. А выше почему-то заявляли, что для этого нужно задействовать модуль с пользователями.

нет, не модулем статей)

Я не поленился и нашёл:

ога. а что если я захочу получить все статьи пользователя. я куда пойду?

в новости, или к пользователям?)

или и к тем, и к другим?)

В статьи, конечно.

Так выборка всех статей автора впринципе в любом отношении должна происходить в модуле статей. Для этого и есть фильтры

нет, не модулем статей)

Ну а где тогда?

Ну а где тогда?

поищи ещё выше

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

Оно?

интересно насколько зашкварный вариант кормить не зависимости, а экземпляр приложения, которое может выдать зависимость через func NewDAO(app *Application) { db := app.GET("componentName") ... }

такой же, падать в рантайме ВС не падать в рантайме

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

надо очередной трекер на все сущности - поехали блин править

зачем апп таскать везде? принимать нужно то, что нужно компоненту? или у вас связность большая?

я уже обьяснил немного выше

что у меня сейчас "по старинке"

я уже обьяснил немного выше

можно передать в dao сразу db

но требования возникают странные, аля "добавить трекер во все dao"

и понеслось...

сначало прокинем зависимость в handlers

от туда прокидываем уже в dao

эти "каскады" править утомительно

а если сделать через приложение, получается я правлю "на концах" и все оки

а если опечатка?

а если кто-то переименует на одном из концов?

ну все "алиасы" который беруться в GET они регистирируются в main

если кто-то полез с непраильным именем - паника

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

в main такое выходит: app := application.NewApplication(logger, appConfig) app.RegisterComponent("scheduler", http.NewSchedulerComponent(app)) app.RegisterComponent("db", db.NewComponent(app)) app.RegisterComponent("webserver", http.NewWebServerComponent(app)) err := app.Preload("db", "scheduler", "webserver") if err != nil { log.Fatal(err) } var wg sync.WaitGroup go app.WithWaitGroup(&wg).Run("webserver") wg.Wait()

интересно насколько зашкварный вариант кормить не зависимости, а экземпляр приложения, которое может выдать зависимость через func NewDAO(app *Application) { db := app.GET("componentName") ... }

классический антипаттерн

ну возможно и зашкварился

думал что-то типо DI cделать

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

типо надо было через рефлект парсить параметры? ?

и подсовывать из "реестра"

слушай, ну сколько можно об этом говорить?)

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

di в го это вообще спорный момент ("автоматизированный")

di - это инъекция зависимостей. Зачем тут рефлект?

di - это инъекция зависимостей. Зачем тут рефлект?

ну есть фабрика условно func NewComponent(db *sql.Conn, anyLib *lib.Conn)

Кто подскажет, как в build mod игнорировать локальные пакеты?

мы же из "униварсального" вызовальщика не знаем какие там параметры и что надо

поэтому напрашивается рефлектом проехаться

и потом уже через рефлект же вызвать

А то, cannot find module for path ...

мне кажется все DI так работают

мне кажется все DI так работают

а, погодь. я не увидел что это фабрика. Тогда да. В фабрику передаешь контейнер, отдаешь инстанс

а, погодь. я не увидел что это фабрика. Тогда да. В фабрику передаешь контейнер, отдаешь инстанс

ну у меня же так и сделано вроде бы O_o

в main идет регистрация компонентов, потом app тягается в аргументе

считай это bulder

ну у меня же так и сделано вроде бы O_o

я подтвердил

конечно это попахивает

но я хз как еще сделать красиво

попахивает именно после вопросов "а для тестирования мы тоже будем контейнер подсовывать?" "а как же ошибки на уровне компиляции?"

интересно насколько зашкварный вариант кормить не зависимости, а экземпляр приложения, которое может выдать зависимость через func NewDAO(app *Application) { db := app.GET("componentName") ... }

основная задница тут в GET, почему просто не положить туда DB как проперти? нафига козобаян?

ну у меня так и было

вернее даже методы

а не свойство

ибо readonly типо

так зачем GET?

хотел более гибкую конструкцию

хотя в принципе можно и вернуть свойства

там фактически когда идет регистрация

вызываются у компонента всякие init

потом load при предзагрузке