PD
Тут и моя вина, мог бы при каком-нибудь рефакторинге предусмотреть )
Size: a a a
2020 June 11
PD
Тогда еще было гораздо проще хотя бы на фронте его убрать
PD
Я делал материал для внутреннего обучения сотрудников.
Архитекторы люди занятые, проще сразу отдать файл:
https://yadi.sk/i/pdkSVGxJ3bXscA
Архитекторы люди занятые, проще сразу отдать файл:
https://yadi.sk/i/pdkSVGxJ3bXscA
Из этого хорошая книжка получится
RT
у нас регулярно пытаются создать какой-нибудь обобщейнный type, архитекторы регулярно это запрещают)
PD
Кстати, а почему CRUD service - антипаттерн? В какой-нибудь луковице это вполне нормально.
Если на него не фронтенд смотрит, а какой-то сервис бинес-логики.
Если на него не фронтенд смотрит, а какой-то сервис бинес-логики.
RT
Кстати, а почему CRUD service - антипаттерн? В какой-нибудь луковице это вполне нормально.
Если на него не фронтенд смотрит, а какой-то сервис бинес-логики.
Если на него не фронтенд смотрит, а какой-то сервис бинес-логики.
Нарушается принцип инкапсуляции, данные в сервисе, а логика домена где-то снаружи. Так сервис не контролирует свое поведение, а является лишь интерфейсом к БД.
Бизнес-логика множится по внешним сервисам.
Бизнес-логика множится по внешним сервисам.
RT
CRUD я имел в виду на уровне логики, а не формата API. API пожалуйста делайте как CRUD если удобно, но логику держите внутри сервиса.
PD
Ну, иногда и правильно, что множится, если сущность включена во много разных процессов.
Ну, например, "пользовательская история операций" - вполне себе EntityService...
Ну, например, "пользовательская история операций" - вполне себе EntityService...
PD
И вполне логично, что логика формирования, как и логика более точного отображения - где-то снаружи. А внутри - просто эффективный cRud
RT
Сервис истории предоставляет внешним системам лишь чтение ленты операций, а не запись туда всего чего попало в любом порядке. Формирование событий ленты истории это вполне себе логика прикладных систем.
PD
Ну, да, у сервиса два API - для R и для CUD )
PD
Но это все равно entity service
RT
Скажем операция совершается в некоем сервисе, прилетает как рассылка события по системе через Kafka, в том числе и в историю (и в другие системы тоже). При этом внешним системам сервис истории предоставляет только функцию чтения ленты истории.
PD
Ну, получить событие из кафки - это тоже API и тоже в рамках CRUD.
Он же не умеет понимать 20 разных форматов этих событий и по каждому укладывать разное в историю, это была бы избыточная зависимость для него.
Он же не умеет понимать 20 разных форматов этих событий и по каждому укладывать разное в историю, это была бы избыточная зависимость для него.
RT
Ну, получить событие из кафки - это тоже API и тоже в рамках CRUD.
Он же не умеет понимать 20 разных форматов этих событий и по каждому укладывать разное в историю, это была бы избыточная зависимость для него.
Он же не умеет понимать 20 разных форматов этих событий и по каждому укладывать разное в историю, это была бы избыточная зависимость для него.
обрати внимание что сервис истории читает события других сервисов, но функцию записи в историю не предоставляет
PD
Не вижу разницы. Может из кафки читать, а может другим давать записывать. Все равно желающий записать событие в историю - знает, что нужно послать.
PD
Синхронное или асинхронное API, оркестрация или хореография - не важно в данном случае.
PD
(У нас как раз окрестрация и синхронное - так что именно предоставляет возможность записать)
RT
Разница есть при соблюдении правила что топики Кафки создаются как каналы рассыхки исходных событий по сервисам системы, а не как труба для наливки данных в конкретного получателя
PD
Ну, это если хореография )