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

Очень сильно, огромное спасибо за перевод!

Так и не понял что плохого делает разработчик "записи к врачу" (наоборот я считаю что делает он хорошую, полезную вещь), ну да ладно.

Ну как видите тут имеет место быть слой подрядов и, в чем я уверен, субподрядов. Тоесть разрабочик услуг и разработчик ДЭГ могут быть буквально в разных концах света. И при этом первый почему то ответственен за второго, я этого решительно не понимаю и видимо не пойму.

Портал 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 у репозитория. Представляет ли автор как будет выглядеть реализация этого метода, когда у агрегата будет допустим пять связанных сущностей или коллекций, а у этих коллекций будут свои связанные сущности?