В рейтинге участвует:

групп:

каналов:

Виртуальный сервер на SSD - недорого!

Аренда выделенных и виртуальных серверов (VDS/VPS), хостинг, аренда IP-адресов, администрирование, круглосуточная поддержка

qwarta.ru подробнее

Резервное копирование с проверкой на вирусы!!!

Удобный сервис создания резервных копий на любой сервер сети интернет. Отслеживайте изменения, проверяйте на вирусы. Надежно защитите свой бизнес!

go.backupland.com

Выбираете сервер? Любая конфигурация на заказ!

Аренда физических серверов любых конфигураций под любые запросы - 1С бухгалтерия, игровые сервера, нагруженные проекты, интернет-магазины!

qwarta.ru подробнее

Size: a a a

Software Design/Architecture/Zen

1938 membersпожаловаться на группу
2021 February 10

MG

Max Grom in Software Design/Architecture/Zen
Ну зачем так сразу? Swagger с головой решает вопрос публичного/выборочного доступа к спецификации лежащей в чужом приватном репозитории. Это полностью покрывает кейс автора без вдавания в подробности есть там у него потребители с контрактами или нет
источник
19:50пожаловаться#1

SP

Sergey Protko in Software Design/Architecture/Zen
Сергей Моисеев
А если эти интерфейсы поместить в слое Приложения, а реализацию в инфраструктуру?
Приложение настолько простое (по сути пересылает данные из одного источника в другой), что там просто нет бизнес-логики.
тоже норм.
источник
20:00пожаловаться#2

YG

Yury Golikov in Software Design/Architecture/Zen
Сергей Моисеев
Стоит ли определять интерфейсы классов в слое Предметной области, если их использует только слой Приложения?
Ты упоролся. Постарайся смотреть шире и понимать что и зачем ты делаешь, а не тупо следовать советам
источник
20:00пожаловаться#3

SP

Sergey Protko in Software Design/Architecture/Zen
Max Grom
Обсуждать, менять и версионировать можно и не в отдельном репозитории. На вкус и цвет
у меня вообще монореп и все в одном.
источник
20:00пожаловаться#4

YG

Yury Golikov in Software Design/Architecture/Zen
А то потом все в этих бесполезных интерфейсах
источник
20:01пожаловаться#5

SP

Sergey Protko in Software Design/Architecture/Zen
Yury Golikov
А то потом все в этих бесполезных интерфейсах
ну может лучше иметь кучу бесполезных интерфейсов с одним-двумя методом в каждом чем классы на 100 методов как обычно любят делать с теми же репозиториями
источник
20:02пожаловаться#6

SP

Sergey Protko in Software Design/Architecture/Zen
но в целом да, надо разобраться ради чего это все делается и возможно "это и не нужно вовсе". Слои не папки. это виртуальный концепт что бы "удобно джунам объяснять разделение ответственности".
источник
20:02пожаловаться#7

YG

Yury Golikov in Software Design/Architecture/Zen
Sergey Protko
ну может лучше иметь кучу бесполезных интерфейсов с одним-двумя методом в каждом чем классы на 100 методов как обычно любят делать с теми же репозиториями
Ну я про то, что не нужно отдельно делать еще сам интерфейс. Пусть это просто будет модуль с двумя функциями или класс. А то любят понатыкать интерфейсов на границах слоев, которые вообще ни для чего не нужны - полностью повторяют сигнатуры функций в модулях
источник
20:04пожаловаться#8

YG

Yury Golikov in Software Design/Architecture/Zen
Сергей Моисеев
А если эти интерфейсы поместить в слое Приложения, а реализацию в инфраструктуру?
Приложение настолько простое (по сути пересылает данные из одного источника в другой), что там просто нет бизнес-логики.
Скорее всего тебе вообще лишние слои не нужны.
источник
20:05пожаловаться#9

СМ

Сергей Моисеев... in Software Design/Architecture/Zen
В Сервис приложения инжектится реализация для источника данных и отдельная для получателя.
Комбинации источник/получатель могут быть разными.
источник
20:05пожаловаться#10

YG

Yury Golikov in Software Design/Architecture/Zen
Сергей Моисеев
В Сервис приложения инжектится реализация для источника данных и отдельная для получателя.
Комбинации источник/получатель могут быть разными.
Следи просто за направлением зависимостей, что кто юзает и выделяй новый модуль/класс если видишь, что они по разным причинам меняться. Не обязательно пытаться относить что то к инфраструктуре или бизнесу
источник
20:12пожаловаться#11

YG

Yury Golikov in Software Design/Architecture/Zen
Грань тонкая, главное чтобы названия у модулей были хорошими и было понятно, кто что делает
источник
20:12пожаловаться#12

СМ

Сергей Моисеев... in Software Design/Architecture/Zen
Спасибо, поэкспериментирую
источник
20:15пожаловаться#13

СМ

Сергей Моисеев... in Software Design/Architecture/Zen
Yury Golikov
Ну я про то, что не нужно отдельно делать еще сам интерфейс. Пусть это просто будет модуль с двумя функциями или класс. А то любят понатыкать интерфейсов на границах слоев, которые вообще ни для чего не нужны - полностью повторяют сигнатуры функций в модулях
Это когда сами модули реализуют свои интерфейсы?
источник
20:25пожаловаться#14

YG

Yury Golikov in Software Design/Architecture/Zen
Сергей Моисеев
Это когда сами модули реализуют свои интерфейсы?
Я про то, что не всегда нужны интерфейсы как отдельные сущности. Сигнатуры достаточно.
источник
20:27пожаловаться#15

СМ

Сергей Моисеев... in Software Design/Architecture/Zen
Насколько я понимаю всё, что связывается с файловой системой, сетью, временем или случайными данными лучше разделять на интерфейс и реализацию.
источник
20:32пожаловаться#16

YG

Yury Golikov in Software Design/Architecture/Zen
Сергей Моисеев
Насколько я понимаю всё, что связывается с файловой системой, сетью, временем или случайными данными лучше разделять на интерфейс и реализацию.
Зачем?
источник
20:34пожаловаться#17

СМ

Сергей Моисеев... in Software Design/Architecture/Zen
Yury Golikov
Зачем?
Для тестирования клиентов
источник
20:36пожаловаться#18

YG

Yury Golikov in Software Design/Architecture/Zen
Сергей Моисеев
Для тестирования клиентов
Хм, а что у тебя за ЯП? Мне в джаве классов для этого хватает
источник
20:37пожаловаться#19

СМ

Сергей Моисеев... in Software Design/Architecture/Zen
Yury Golikov
Хм, а что у тебя за ЯП? Мне в джаве классов для этого хватает
Мы может быть о разном говорим, я имел ввиду юнит-тестирование
источник
20:45пожаловаться#20