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

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

Гидратация в гошке может реализована кучей способов, в каких-то случаях на уровне реализации тех или иных интерфейсов к тем или иным инструментам, например, драйверам БД.

В принципе тот пример, что я прислал, это вполне себе, да, гидратация, но опять же, насколько важно иметь приватные поля в том слое, в котором вы работаете с объектом?
Иногда мы пытаемся использовать один и тот же золотой молоток там, где в действительности в этом нет необходимости.
К примеру ограничить видимость полей иногда можно просто используя интерфейсы, причём зачастую это будет даже правильней, просто потому что проще, а простота — часто залог стабильности)

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

по сути у меня есть сущность User с разным набором полей, видимым должен быть только ИД
остальные поля меняются посредством команд для изменения состояние, учитывая что команды это методы самой структуры, то они имеют доступ к приватным полям
таким образом я надеялся спрятать от вызывающего информацию о внутреннем устройстве User давая доступ только к методам изменяющим стейт которые в свою очередь позаботятся о консистентности

Это всё понятно.
Вопрос-то в другом: от кого вы собрались прятать состояние? Если эта сущность используется только в вашей программе, то есть ли в этом смысл? Ответ на этот вопрос зависит от нескольких факторов: масштаб программы, количество разработчиков и т.д.

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

Опять же, я не берусь утверждать, что вам эта инкапсуляция не нужна. Может как раз вам-то и нужна. Моё дело — обратить внимание на это, чтоб вы сами ответили себе на этот вопрос.

Потому что часто я вижу вот такой код:

type Entity struct {
  firstName string
  lastName  string
}

func (e Entity) GetFirstName() string {
  return e.firstName
}

func (e *Entity) SetFirstName(firstName string) string {
  e.firstName = firstName
}

func (e Entity) GetLastName() string {
  return e.lastName
}

func (e *Entity) SetLastName(lastName string) string {
  e.lastName = lastName
}

И на вопрос: "а зачем?", — человек тоже что-то про инкапсуляцию, безопасность и вот это вот всё говорит.

type Entity struct {
  firstName string
  lastName  string
}

func (e Entity) GetFirstName() string {
  return e.firstName
}

func (e *Entity) SetFirstName(firstName string) string {
  e.firstName = firstName
}

func (e Entity) GetLastName() string {
  return e.lastName
}

func (e *Entity) SetLastName(lastName string) string {
  e.lastName = lastName
}

ну тут явное нарушение инкапсуляции, такое не может быть сущностью, это просто ValueObject

Да нет, нет здесь нарушения инкапсуляции, здесь просто по сути нет никакой инкапсуляции.
Ну то есть на бумаге есть условная, а фактически — просто бред)

подскажите пожалуйста правильно ли я понял идею как прятать за интерфейсом сущности ?
https://play.golang.org/p/Z3GGC-KFzMW
(вообще это код пакета User, просто плейграунд не разрешает пакеты делать)

ты не используешь интерфейс нигде

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

ну если используется но с виду все норм

единственное интерфейс я бы вынес как независимую еденицу

конкретно в твоем случае я не виду причин использовать интерфейс, он 100% дублирует твою сущность

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

был бы смысл если бы у тебя было бы 2 сущности с похожим действием

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

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