зачем делят слои на разные пакеты?
К примеру почему бы если мы работаем с книгами не сделать один пакет book
и в нем три файла:
model.go - сама сущность
usecase.go - бизнес-логика
store.go - работа с базой где это хранится
ну а так же другие интерфейсы/адаптеры:
rest.go
grpc.go
…
чувствую, что я что-то не понимаю
но на мой взгляд так было бы проще работать с кодом
что я не учитываю?
У вас usecase может работать не только с книгами, а еще с чем-нибудь
https://ru.wikipedia.org/wiki/SOLID_(%D0%BE%D0%B1%D1%8A%D0%B5%D0%BA%D1%82%D0%BD%D0%BE-%D0%BE%D1%80%D0%B8%D0%B5%D0%BD%D1%82%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%BD%D0%BE%D0%B5_%D0%BF%D1%80%D0%BE%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D0%B5)
Аргумент
Может быть это аргумент Но для меня слишком обще Я прочитал указанную Вами страницу и не увидел проблем в моем рассуждении Можно пожалуйста более детально ткнуть носом?
Как быть с бизнес-логикой где несколько сущностей?
Ты DDD ща озвучил
И что именно ты хочешь хранить в model?
Уже выше написали Да, это аргумент У меня нет прямого ответа При этом если бизнес-логика работает только с одной сущностью (а часто так и бывает), то тогда такая схема логичная
В бд храним ту же сущность что и в БЛ используем? И ту же, что наружу отдаём по api?
Ну в моем примере со сферической книгой в вакуме в принципе да
Если наружу надо отдать не все поля? Если в БЛ надо полей больше, чем у той сущности что в БД?
я бы разве что сделал поправку на ГО - https://dave.cheney.net/2016/08/20/solid-go-design
Обсуждают сегодня