Круто. Нужно было просто сказать «юзайте интерфейсы, с помощью di делайте декорации на их основе. А чтобы провайдить функционал из сервис-леера в контроллеры, юзайте интерфейс фасадов сервис-леера :)
Только непонятно, что нового открыл для нас этот AI чего раньше не было в туториалах/литературах ?)
Есть такой прекрасный паттерн как Saga. Бывает она оркестрируемая, а бывает хореографией. Если очень супер-грубо говоря, то мы должны иметь не только точки входа и выполнения какой-то операции, но и алгоритм компенсирующих транзакций. А так же, каждый модуль должен быть полностью автономным по отношению к другим. ( разве что общение через контракты в виде публичных интерфейсов и DTO ).
Но тут, перед началом внедрения подобных подходов, нужно прочитать про принципы DDD. Тогда будет понятно как реализовать действительно изолированные модули.
Потом можно изучить как работает EventSourcing. Кстати, подробная информауция есть на microservices.io. Жаль, примерчики там какие-себе.
Грег Янг, кстати, неплохую макулатуру написал на эту статью.
Кстати, можно , конечно, реализовывать свой велосипед на 3х вышепересисленных мессаж-брокерах, А можно заюзать что-то подобное на, скажем, Temporal (начинался с Uber Cadence) в связке с Roadrunner. Попробуйте глянуть, забудете что такое эти все SQS, Rabbit, etc...
P.S. Оценил, что упомянули про идемпотентность. действительно полезная штука, особенно когда случайно от магазина электроники получаешь 100см подряд о том, что пора воспольщоваться скидкой на <N> продукты ))
Круто. Нужно было просто сказать «юзайте интерфейсы, с помощью di делайте декорации на их основе. А чтобы провайдить функционал из сервис-леера в контроллеры, юзайте интерфейс фасадов сервис-леера :)
Только непонятно, что нового открыл для нас этот AI чего раньше не было в туториалах/литературах ?)
Идея неплохая, но реализция хромает.
Есть такой прекрасный паттерн как Saga. Бывает она оркестрируемая, а бывает хореографией. Если очень супер-грубо говоря, то мы должны иметь не только точки входа и выполнения какой-то операции, но и алгоритм компенсирующих транзакций. А так же, каждый модуль должен быть полностью автономным по отношению к другим. ( разве что общение через контракты в виде публичных интерфейсов и DTO ).
Но тут, перед началом внедрения подобных подходов, нужно прочитать про принципы DDD.
Тогда будет понятно как реализовать действительно изолированные модули.
Потом можно изучить как работает EventSourcing. Кстати, подробная информауция есть на microservices.io. Жаль, примерчики там какие-себе.
Грег Янг, кстати, неплохую макулатуру написал на эту статью.
Кстати, можно , конечно, реализовывать свой велосипед на 3х вышепересисленных мессаж-брокерах,
А можно заюзать что-то подобное на, скажем, Temporal (начинался с Uber Cadence) в связке с Roadrunner. Попробуйте глянуть, забудете что такое эти все SQS, Rabbit, etc...
P.S. Оценил, что упомянули про идемпотентность. действительно полезная штука, особенно когда случайно от магазина электроники получаешь 100см подряд о том, что пора воспольщоваться скидкой на <N> продукты ))