всего и не на этом нужно задумываться
я сейчас делаю клиент серверное приложение
клиент cli и grpc сервер
с сервером все более менее понятно
есть хендлеры которые реализуют grpc сервер, рядом объявляю юзкейс интерфейс
имплементацию юзкейсов в другом месте
а вот с клиентом как быть? понимаю что тут тоже свои юзкейсы, в юзкейсах обращаться клиенту grpc?
и подскажите еще
у меня сейчас так
internal
- uscase\user
- reposetory\user\boltdb
- delivery\grpc\user
и тут получился код который касается сервера
а случайно не правильнее будет сделать
internal
- client
- server
?
Вопросы правильные, но для понимания того, как нужно структуру описывать зависит от задач и типа архитектуры. Если разделение по домену, то максимально отделять реализацию, если бизнес логики минимум, то просто по назначению. И названия для директорий выбирать не максимально абстрактные, а максимально конкретные, чтобы не было искушения добавить что-то, что не имеет к этому отношения. Структура директорий обычно пытается максимально описывать архитектуру. В каждом конкретном случае она может быть своя. А вот общие названия чисто для удобства и лёгкости запоминания. Если что, где-то даже Russ Cox про это писал
client взаимодействует с этим сервером через API?
да, grpc, прото в этойже репе
Тогда да, делал бы client отедльно как в последнем варианте
понял, cпасибо читал что название пакетов лучше делать максимально краткими, лаконичными
спасибо, попробую так понимаю что можно и например общие модели вынести на один уровень с сущностями client и server
Только не утрировать с этим) чтобы для поиска такого имени в Оксфордский словарь за редким лаконичным термином не пришлось ходить и потом вспоминать, а что же оно обозначало )
Сомнительно. Модели принадлежат серверу, клиент может их импортировать оттуда для удобства
Обсуждают сегодня