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

https://github.com/bxcodec/go-clean-arch
https://medium.com/@manakuro/clean-architecture-with-go-bce409427d31

Это можешь почитать

репа с примером простым и статья

Нет, конечно, просто вы соорудили Франкенштейна с репозиторием в json-файлах.
Если вы хотите DDD, то вы в любом случае будете писать набор адаптеров/конвертеров/фабрик и т.д., потому что доменная сущность живёт только в доменном слое, а на уровне хендлеров вам нужны другие структуры данных (даже если они такие же).

Но опять же, вам пример слишком синтетический.
Программа пишется от простого к сложному, а вы сразу начинаете городить кучу абстракций.

Для большей половины программ, к слову, можно и из хендлеров сразу в базу ходить — это нормально, когда у вас программа состоит из одной сущности и двух методов, например.
Все эти слои нужны, когда нужны.

благодарю, пошел читать

господа, подскажите как выйти из такой непонятки
метод репозитория имеет следующую сигнатуру
func (m userMemoryStorage) GetById(id User.Id) (User.User, error)

как бы все понятно тут
но что делать когда необходимо вернуть ответ в случае ошибки в методе ? не важно какой
собственно мне видится return User.User{}, errors.new("...")

но мне кажется это не очень правильным, хотелось бы возвращать nil вместо пустого юзера
однако голанг это не позволяет мне

чтобы возвращать nil мне нужно изменить сигнатуру метода на
func (m userMemoryStorage) GetById(id User.Id) (User.UserInterface, error)

но в интерфейсе я не могу указывать поля которые будут изменять данные структуры (методы структуры с указателями func (u *User) Activate() например)

я возвращаю пустую структуру и ошибку, у меня всегда в начале метода есть образно такой кусок  var result User.User и его я возвращаю при ошибке, если нет, заполняю

я просто не люблю использовать указатели без явной надобности

> но мне кажется это не очень правильным, хотелось бы возвращать nil вместо пустого юзера

да все норм возвращать пустого) вызывающий же должен ошибку проверить в первую очередь

А если вызывающий идиёт как я :) забудет. Я ещё не привык

тогда ты запаникуешь и у тебя приложение упадет

если будет нул

Главное — принять и следовать одному простому правилу: если возвращается ошибка, то все значения, идущие в кортеже с ней — нулевые.
Это касается, как возврата из функции, так и использования результатов.
То есть либо данные с nil-ошибкой, либо ошибка и zero-value данные.

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

Исчерпывающе. Спасибо

на таких вызывающих есть 2 приема:
- линтеры
- паника

А есть какие то правильные способы обработки ошибок ?
Делать после каждого вызова if err != nil как то не очень
Сделать для этого отдельную глобальную функцию в целом можно, но пока эта идея в загашнике
CheckError(err interface{}, message string)

тебе ведь нужно отреагировать на ошибку, вернуть что-то, прервать программу, по этому придется всегда if err != nil  делать

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

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