будет маршалить в новом новый объекте в "new_x"?
Это один кейс, тогда надо 2 структуры, и у первой сделать метод преобразования (чтобы на выходе классически ссылка на другой объект + ошибка).
Ну и конечно сами преобразования переобернуть хорошо в свои функции с проверками и валидацией. Например если функция 500+: 99% что pr не пущу, тк это не читабельно.
Если надо преобразовать в тот же объект с теми же полями - две структуры нафиг не нужны. В остальном +- так же, метод структуры, только работающих "сам с собой", возврат только ошибки.
Минута архитектуры:
получив объект, провалидировать его, разворотить/обогатить данные/сделать свою доп магию => передать в фасад программы, в котором описана нужная реализация этого юзкейса через нужный интерфейс.
Но это уже "сложнааа", и всем лень делать. Хотя такая архитектура годнота: https://herbertograca.com/2017/11/16/explicit-architecture-01-ddd-hexagonal-onion-clean-cqrs-how-i-put-it-all-together/
https://github.com/mmkhitaryan/drawio/blob/master/main.go
Обсуждают сегодня