Погуглил, ДЭГ это точно = гос услуги? Вы считаете что разработчик который ответственен за условную "запись к врачу" как-то причестен к разработке ДЭГ'а?
Так и не понял, зачем нужен отдельный коннекшн для лока? И в чем смысл вашей uow? Я так всегда думал что uow накапливает внутри (а не в бд) изменения в домене и выпуливает их в бд после uow.commit, такой подход позволяет, например, схлопнуть update entity + delete entity до delete entity на этапе переноса изменений домена в бд.
По идее можно сделать пул потоков для файлового I/o через пул горутин + runtime.LockOsThread и raw сисколы. А так да io_uring решает проблему с асинхронными операциями на файлах, хоть в ядре всеравно будет тот же пул воркеров :)
В оперативной памяти же массивы выглядят просто как последовательность значений одного размера. Они занимают фиксированный объем и имеют постоянное расположение в памяти на всё время жизни, пока за ними не придет сборщик мусора.
Это не совсем так, расположение в памяти может меняться потому что есть механизм stack grow. В случае алокации в куче на практике фиксированно (потому что гц не мувит в настоящий момент), но GO не дает гарантий что адрес не может поменяться.
Интересная штука, спасибо. Но, мое мнение, для DDD не подойдет тк заставляет прокидывать в сущности свои методы. Это противоречит сути DDD - код домена должен отражать суть домен, в данном случае в домен пролезет слишком много инфраструктурных подробностей.
Не на go есть некоторый инструмент (hybernate, entity fw, doctrine) достаточно умный чтобы следить за каждым узлом в графе сущностей (тн агрегат) и при его изменении/удалении/появление нового узла переносить эти изменения в базу данных.
Это именно тот вопрос, который очень старательно обходят стороной подобные статьи. Ведь если автор возьмет не банальную сущность заказ, а нечто действительно сложное (а зачем нам иначе DDD?) то код какого нибудь Update написанный руками отпугнет всякого.
Отвечая на ваш вопрос - в GO никак, инструменты которые позволяют сохранять графы объектов не взлетают, потому что никому особо не нужны тк в микросервисах DDD не часто нужен.
Хорошая статья для новичков и для введения в DDD. Конечно печалит наличие метода Update у репозитория. Представляет ли автор как будет выглядеть реализация этого метода, когда у агрегата будет допустим пять связанных сущностей или коллекций, а у этих коллекций будут свои связанные сущности?
Я говорил о лечении симптома - просто добавили sync.Once - победили лишний парсинг каждый раз на реквест. Не более.
Если мы говорим о лечении болезни то надо изначально сделать значение url'a конфигурируемым и добиться того чтобы в структуру trudVsem прокидывался *url.URL на этапе создания этой структуры (если хотите на этапе инициализации). А из строки в url.URL мы преобразовываем на этапе чтения конфигурации.
var u *url.URL
var o = &sync.Once{}
func main() {
o.Do(func() {
u, _ = url.ParseRequestURI("http://google.com")
})
print(u.String())
}
Если once.Do вы оставите внутри рассматриваемой функции, тогда это будет работать только при условии, что запуск функции в разных рутинах не пересечется
Нет это будет работать безопасно, я в посте дал ссылку на memory model
Портал gosuslugi.ru и государственная услуга как таковая это же разные вещи.
Ну опять же, сначала надо доказать что действительно "за соседней стеной". В данном случае я прямой связи не вижу.
Погуглил, ДЭГ это точно = гос услуги? Вы считаете что разработчик который ответственен за условную "запись к врачу" как-то причестен к разработке ДЭГ'а?
А что плохого в разработке каких нибудь гос-услуг, которые помогают буквально каждому гражданину?
Так и не понял, зачем нужен отдельный коннекшн для лока?
И в чем смысл вашей uow? Я так всегда думал что uow накапливает внутри (а не в бд) изменения в домене и выпуливает их в бд после uow.commit, такой подход позволяет, например, схлопнуть update entity + delete entity до delete entity на этапе переноса изменений домена в бд.
Спасибо за такую оценку!
По идее можно сделать пул потоков для файлового I/o через пул горутин + runtime.LockOsThread и raw сисколы. А так да io_uring решает проблему с асинхронными операциями на файлах, хоть в ядре всеравно будет тот же пул воркеров :)
Это не совсем так, расположение в памяти может меняться потому что есть механизм stack grow. В случае алокации в куче на практике фиксированно (потому что гц не мувит в настоящий момент), но GO не дает гарантий что адрес не может поменяться.
Судя по бенчмарку Вы JS тут забыли
Собственно выше написал почему с ent не построить хорошую доменную модель.
Справедливо, но ведь в таком случае и оптимизировать путем перехода на http - не выйдет.
Интересная штука, спасибо. Но, мое мнение, для DDD не подойдет тк заставляет прокидывать в сущности свои методы. Это противоречит сути DDD - код домена должен отражать суть домен, в данном случае в домен пролезет слишком много инфраструктурных подробностей.
А зачем в закрытом контуре https? Чтобы героически его отключить?)
Не на go есть некоторый инструмент (hybernate, entity fw, doctrine) достаточно умный чтобы следить за каждым узлом в графе сущностей (тн агрегат) и при его изменении/удалении/появление нового узла переносить эти изменения в базу данных.
Это именно тот вопрос, который очень старательно обходят стороной подобные статьи. Ведь если автор возьмет не банальную сущность заказ, а нечто действительно сложное (а зачем нам иначе DDD?) то код какого нибудь Update написанный руками отпугнет всякого.
Отвечая на ваш вопрос - в GO никак, инструменты которые позволяют сохранять графы объектов не взлетают, потому что никому особо не нужны тк в микросервисах DDD не часто нужен.
Хорошая статья для новичков и для введения в DDD. Конечно печалит наличие метода Update у репозитория. Представляет ли автор как будет выглядеть реализация этого метода, когда у агрегата будет допустим пять связанных сущностей или коллекций, а у этих коллекций будут свои связанные сущности?
Стоп стоп, вы хотите лечить симптом или болезнь?
Я говорил о лечении симптома - просто добавили sync.Once - победили лишний парсинг каждый раз на реквест. Не более.
Если мы говорим о лечении болезни то надо изначально сделать значение url'a конфигурируемым и добиться того чтобы в структуру trudVsem прокидывался *url.URL на этапе создания этой структуры (если хотите на этапе инициализации). А из строки в url.URL мы преобразовываем на этапе чтения конфигурации.
Ошибка здесь не просто маловероятна. Учитывая что мы парсим константу идемпотентной операцией - не проверять тут ошибку вполне нормально.
По поводу много сложный вещей внутри Do - да он не для этого, но и я предложил использовать его только в конкретном кейсе инициализации.
Все верно, это safe код, а в чем но?
Нет это будет работать безопасно, я в посте дал ссылку на memory model
del