Сам когда-то не понимал этой логики, но нашёл удобным по следующей причине: Service - валидация, сериализация, первичная обработка данных короче, ну и формирование ответа Use case - непосредственно бизнес логика В достаточно больших приложениях, вернее даже в приложениях с большими моделями для запросов/ответов - удобно. В маленьких - это не нужно
Хороший доклад, мы к такому же пришли, ну точнее чел с опытом в DDD нас направил на путь истинный. Единственно не стали сильно глобалить entity чтоб аж json в них прописывать. И usecase у нас может работать с репо. Зачем писать service для get-ручки? Handler вызывает facade, facade вызывает usecase или facade может сам в репо сходить. Хотя это вопрос конечно как логику приложения делить между usecase и service. Ну и не пишем в каждом сервисе interface для репо из одного метода. Репо-интерфейсы вынесены в порты (архитектура порты & адаптер) и каждый сервис импортит порт. А если нужен все таки интерфейс для сервиса, то у нас он exported, а не внутренний для пакета. Когда интерфейс с lower case именем понятно что он под внутренние цели. Но у нас они в upper case как признак того что это внешняя зависимость.
Начал за здравие, кончил - за упокой) Про глобальные entity. С одной стороны верно, т.к. главное правило зависимостей соблюдается. Т.е. есть центральные бизнес-сущности (entity), которые не зависят ни от чего. А репозитории и контроллеры - зависят от них. Зря не любишь круглую диаграмму. Если на ней нарисовать стрелки зависимостей, то увидишь, что все стрелки идут в центр. Т.е. переферия зависит от бизнес-ядра. DTO для того и нужно, чтобы укоротить стрелки, чтобы разорвать зависимость между ядром и контроллером. Вот ты у entity переименовал поле или удалил. И сигнатура АПИ тут же ломается. Между ними как раз должен быть промежуточный DTO, который на себя возьмёт роль поддержания совместимости. Вот там нормально выглядят json теги.
это еще добавит слой мапперов из дто в ентити и обратно + тесты. зависит от размера проекта конечно, но если это сервис ближе к микро, чем к макро, то имхо подход Тиграна сильно упрощает. Особенно учитывая что там и так достаточно много бойлерплейта, особенно на этапе инициализации. В авито плюс-минус к тому же пришли в итоге. Удобно, особенно покрывать тестами каждый слой независимо
А ведь каких-то лет пять назад гошники при упоминании чистой архитектуры начинали шипеть что-то вроде "валите обратно в свою жабу". Глобальные entity дабы не делать dto - может и имеет право на жизнь. Но всё-таки идея перекидывать между слоями определенные data structure несет не только изоляцию слоев, но и возможность эти самые ds кастомизировать под необходимости конкретных слоёв. entity всёж по определению предельно чисты и не содержат ничего от следующих слоёв.
Нельзя использовать глобальные структуры entity, потому что го - это язык строгой типизации, а в реализации интерфейсов данные могут храниться в отличных форматах, поэтому entity выделены в отдельный слой не просто так, а для того, чтобы быть связующим звеном между всеми слоями абстракции. Если вы используете глобальные entity, ваш код становится связанным этими entity, смыл же чистой архитекруты - развязать слои и сделать их независими друг от друга и от конкретной реализации.
Молодец, но почему бы просто не реализовать архитектуру как по книжке и не делать не пойми что, в итоге проблем не оберетесь, сделали бы все глобальное, зачем вам принцип инверсии ? в общем за опыт плюс, за все остальное минус
paymenter userer subscripter =) думаю, можно обойтись без usecase, а может даже без service также, я бы не советовал писать сущности с экспортируемыми полями - это ломает инкапсуляцию поведения
Ломает да, только в Go от этого никуда не денешься, т.к. не сможем анмаршалить/маршалить структуры из/в json/db/... По этому как было сказано в видео можно городить всякие мапперы,гидраторы и прочие преобразователи.
Я решил добавить чучуть больше аргументов против использования термина usecase (случай использования или пользовательский случай). Боб просто обобщил бизнес-логику назвав это usecase, но такое определение в коде делает его сильно шаблонным. Не знаю, может у меня просто такое отношение, ведь мне кажется логичнее назвать это, ну скажем, хотябы domain. Простите за занудство, ведь мы все прекрасно знаем, что на названия программист тратит 90% времени. 😀
@@alex-0x6b Есть чёткое ощущение, что Вы неверно понимаете Чистую Архитектуру и понятие "usecase" в частности. По-русски это будет "Вариант использования", а по смыслу "Бизнес-правила, связанные в конкретным приложением". "domain" - это неверное название (неконкретное). Пример: у вас служба записи к врачу. 1. Критические бизнес-правила (самое ядро, сущности, entity) - это про врачей, пациентов, болезни и график работы. Т.е. то, что существует без всяких приложений. Эти сущности из реального мира, они существовали еще когда не было никакого интернета. 2. usecase - Это то, что связано с конкретным приложением. Например, процедура регистрации на сайте через веб, отображение информации о враче на одной карточке вместе с фоткой. Это то, что вроде как рядом с "доменом", но чётко завязано на конкретное веб-приложение. Мобильное приложение для записи к врачу - это второй usecase, у него и процедуры регистрации другие, и протоколы и форматы данных и т.д. "Доменом" обычно называют эти две области вместе. Либо критические бизнес-правила плюс небольшая часть из usecase.
Usecase - это буквально переводится как бизнес-сценарии, самое подходящее название. Ниже вы предложили domain.. domain - это буквально предметная область, название не передаёт прямой сути (как и "сервисы")
Автор искренне делится опытом. Благодарю! Видно, что волнуется и мало опыта выступлений. А ещё много англицизмов и сленга. Беда не сколько в их наличии, а в том, что их много и они неуместны. Создаётся впечатление, что ими какие-то пробелы в аргументации или понимании закрываются.
Данная профессия полна англицизмов и сленга, так что это более чем приемлимо. Особенно с учётом того, что исходная информация обычно на английском языке.
большое спасибо за доклад, все кратко по дело. Отдельное спасибо за пакет goro
спасибо за свой опыт. Можно ли указать какой-либо публичный репозиторий, чтобы посмотреть это в коде?
Мне очень понравилось, но так и не понял зачем вводить дополнительный слой usecase. Почему сам service не может определять usecase?
Сам когда-то не понимал этой логики, но нашёл удобным по следующей причине:
Service - валидация, сериализация, первичная обработка данных короче, ну и формирование ответа
Use case - непосредственно бизнес логика
В достаточно больших приложениях, вернее даже в приложениях с большими моделями для запросов/ответов - удобно. В маленьких - это не нужно
@@GeekanskiY ты неправильно понял, тк сервис не должен заниматься формированием ответа, это прерогатива слоя хендлеров
Спасибо за видео!
Рады стараться!
Хороший доклад, мы к такому же пришли, ну точнее чел с опытом в DDD нас направил на путь истинный. Единственно не стали сильно глобалить entity чтоб аж json в них прописывать. И usecase у нас может работать с репо. Зачем писать service для get-ручки? Handler вызывает facade, facade вызывает usecase или facade может сам в репо сходить. Хотя это вопрос конечно как логику приложения делить между usecase и service. Ну и не пишем в каждом сервисе interface для репо из одного метода. Репо-интерфейсы вынесены в порты (архитектура порты & адаптер) и каждый сервис импортит порт. А если нужен все таки интерфейс для сервиса, то у нас он exported, а не внутренний для пакета. Когда интерфейс с lower case именем понятно что он под внутренние цели. Но у нас они в upper case как признак того что это внешняя зависимость.
А как между всеми этими слоями должны прокидываться ошибки, если эти слои независимые?
Доклад вроде бы хороший, но мне как новичку без наглядного работающего кода не понять что и как между собой взаимодействует
Спасибо за классный доклад. Можно где-то презентацию скачать?
Крутой доклад.
Начал за здравие, кончил - за упокой) Про глобальные entity.
С одной стороны верно, т.к. главное правило зависимостей соблюдается. Т.е. есть центральные бизнес-сущности (entity), которые не зависят ни от чего. А репозитории и контроллеры - зависят от них.
Зря не любишь круглую диаграмму. Если на ней нарисовать стрелки зависимостей, то увидишь, что все стрелки идут в центр. Т.е. переферия зависит от бизнес-ядра.
DTO для того и нужно, чтобы укоротить стрелки, чтобы разорвать зависимость между ядром и контроллером. Вот ты у entity переименовал поле или удалил. И сигнатура АПИ тут же ломается.
Между ними как раз должен быть промежуточный DTO, который на себя возьмёт роль поддержания совместимости. Вот там нормально выглядят json теги.
Не стоит быть столько критичным ;)
@@EvroneDevelopment Не стоит быть таким душнилой, Вы хотели сказать наверное 😂
это еще добавит слой мапперов из дто в ентити и обратно + тесты. зависит от размера проекта конечно, но если это сервис ближе к микро, чем к макро, то имхо подход Тиграна сильно упрощает. Особенно учитывая что там и так достаточно много бойлерплейта, особенно на этапе инициализации. В авито плюс-минус к тому же пришли в итоге. Удобно, особенно покрывать тестами каждый слой независимо
13:50 - если в "слое сервисов есть несколько пакетов, и они могут вызывать друг друга", получится циклический импорт же :(
А ведь каких-то лет пять назад гошники при упоминании чистой архитектуры начинали шипеть что-то вроде "валите обратно в свою жабу".
Глобальные entity дабы не делать dto - может и имеет право на жизнь. Но всё-таки идея перекидывать между слоями определенные data structure несет не только изоляцию слоев, но и возможность эти самые ds кастомизировать под необходимости конкретных слоёв. entity всёж по определению предельно чисты и не содержат ничего от следующих слоёв.
есть N слоёв и M сущностей с мапингом при каждом переходе из слоя в слой. Много ли будет накладной и, скорее всего, бесполезной работы?
@@TheDavBag Идеологи чистой архитектуры открыто пишут, что она стоит заметных дополнительных затрат и бездумно совать ее куда попало не стоит.
@@redneck_prm5429 да, и насколько мне известно, ЧА создавалась для решения задач модульного монолита
На все слои без необходимости не нужно конечно делать, иначе оверинженеринг, но хотя бы с инфрой разделить стоит
а чего без github-а то? :(
спасибо за видео
Рады что вам понравилось!
Нельзя использовать глобальные структуры entity, потому что го - это язык строгой типизации, а в реализации интерфейсов данные могут храниться в отличных форматах, поэтому entity выделены в отдельный слой не просто так, а для того, чтобы быть связующим звеном между всеми слоями абстракции. Если вы используете глобальные entity, ваш код становится связанным этими entity, смыл же чистой архитекруты - развязать слои и сделать их независими друг от друга и от конкретной реализации.
Молодец, но почему бы просто не реализовать архитектуру как по книжке и не делать не пойми что, в итоге проблем не оберетесь, сделали бы все глобальное, зачем вам принцип инверсии ? в общем за опыт плюс, за все остальное минус
Но хэндлер это же тоже адаптер)
Гений!!!
paymenter userer subscripter =)
думаю, можно обойтись без usecase, а может даже без service
также, я бы не советовал писать сущности с экспортируемыми полями - это ломает инкапсуляцию поведения
Ломает да, только в Go от этого никуда не денешься, т.к. не сможем анмаршалить/маршалить структуры из/в json/db/...
По этому как было сказано в видео можно городить всякие мапперы,гидраторы и прочие преобразователи.
@@ДенисДавыдов-ц6х не ломает, надо просто имплементировать Unmarshaller
Называя папку usecase вы жестко привязываетесь к дядюшке Бобу, а оно вам надо?) Считаю это определение максимально неудачным.
У каждого свой путь ;)
Нормальное название) Зато понятно о чём речь!
Я решил добавить чучуть больше аргументов против использования термина usecase (случай использования или пользовательский случай).
Боб просто обобщил бизнес-логику назвав это usecase, но такое определение в коде делает его сильно шаблонным. Не знаю, может у меня просто такое отношение, ведь мне кажется логичнее назвать это, ну скажем, хотябы domain.
Простите за занудство, ведь мы все прекрасно знаем, что на названия программист тратит 90% времени. 😀
@@alex-0x6b Есть чёткое ощущение, что Вы неверно понимаете Чистую Архитектуру и понятие "usecase" в частности. По-русски это будет "Вариант использования", а по смыслу "Бизнес-правила, связанные в конкретным приложением". "domain" - это неверное название (неконкретное).
Пример: у вас служба записи к врачу.
1. Критические бизнес-правила (самое ядро, сущности, entity) - это про врачей, пациентов, болезни и график работы. Т.е. то, что существует без всяких приложений. Эти сущности из реального мира, они существовали еще когда не было никакого интернета.
2. usecase - Это то, что связано с конкретным приложением. Например, процедура регистрации на сайте через веб, отображение информации о враче на одной карточке вместе с фоткой. Это то, что вроде как рядом с "доменом", но чётко завязано на конкретное веб-приложение.
Мобильное приложение для записи к врачу - это второй usecase, у него и процедуры регистрации другие, и протоколы и форматы данных и т.д.
"Доменом" обычно называют эти две области вместе. Либо критические бизнес-правила плюс небольшая часть из usecase.
Usecase - это буквально переводится как бизнес-сценарии, самое подходящее название.
Ниже вы предложили domain.. domain - это буквально предметная область, название не передаёт прямой сути (как и "сервисы")
На хер тогда вышел, раз не успеешь!😄
сказал давайте попишем код ибо по презентации все ясно, а в коде нет
в итоге сам создал через либу проект и ничего толком не показал
30 минут
Автор искренне делится опытом. Благодарю! Видно, что волнуется и мало опыта выступлений. А ещё много англицизмов и сленга. Беда не сколько в их наличии, а в том, что их много и они неуместны. Создаётся впечатление, что ими какие-то пробелы в аргументации или понимании закрываются.
Данная профессия полна англицизмов и сленга, так что это более чем приемлимо. Особенно с учётом того, что исходная информация обычно на английском языке.
че? Все нормально выступил и все фразы уместны
Я бы на его месте больше бы на английском говорил 😂. Но он молодец, старался не делать каши языков