Микросервисы в ERP

[mazzy]

Цитата:

Сообщение от MikeR

У каждого модуля должен быть свой API, через который происходит общение с этим модулем.

Согласен с MikeR.
И сейчас взаимодействие между "модулями" происходит через публичный интерфейс классов. Никто ж в здравом уме не пишет финансовые проводки вручную, а обращаются к классам LedgerVoucher*

другое дело, что классы в аксапте слишком много знают друг о друге.

Цитата:

Сообщение от Lemming

Кроме того, если падает общее приложение то все как бы понятно, поднимать надо все. Если же сервис Главная книга упал, а сервис Продажи ждет от него номер бухгалтерской операции, то чем это будет принципиально отличаться от падения общей БД/приложения?

да, люди столкнулись с этой проблемой.
в результате пришли к стандартизированным менеджерам очередей для сообщений.

сейчас это RabbitMQ, Kafka и подобные (эти живут и здравствуют)
Раньше в виндах был MicrosoftMQ и BizTalk (эти умерли)

Цитата:

Сообщение от Lemming

В общем, идея с микросервисами выглядит с одной стороны заманчиво, потому что помогает избежать большой связанности, но с другой стороны не окажется ли использование микросервисной архитектуры таким же проблемным, каким, в некоторых случаях, оказываются ERP приложения с монолитной архитектурой?

Ну... на самом деле не очень.
История повторяется:
1. раньше были "мощные" мэйнфреймы и тупые терминалы.
2. решили что это не гибко и монстроидально, начали в персональные компьютеры
3. персональные компьютеры изначально были персональными и плохо работали в сети.
4. затем появились сетевой инструментарий для персональных компьютеров
5. теперь снова уходит "в облака", где работают мощные "мэйнфреймы", а персональные компьютеры являются тупыми терминалами по большей части

идея с микросервисами - примерно то же самое.
она привлекательна только для небольших и независимых команд разработчиков.

для совместной работы больших команд микросервисы неудобны и тяжело администрируемы.
читать "монорепа", "моно репозитарий"

если говорить в терминах аксапты,
то кажется, что главная книга, склад, производство и... та-дам... сводное планирование, например, очень хорошо выносится в микросервисы.

Майкрософт так и сделал со сводным планированием. Можно почитать отзывы, посмотреть на результат, так сказать

но когда с уровня космического архитектора спускаешься на уровень реализации, тут же выясняется, что в ERP есть много действительно общих вещей. Валюты и валютные курсы например. Особенно с учётом разных стран, кросс-курсов, управляемых курсов типа УЕ.
А также нормативные справочники типа налоговых инспеций, ИНН/КПП. В Аксапте DirInfo, не к ночи будь помянут... Даже тривиальные финансовые периоды, которые в Аксапте в модуле главной книги. И даже в существующей аксапте они не очень используются....

Стоит примерить как придется реализовать ЭТО в парадигме микросервисов. И сколько этих микросервисов придется сделать.

С другой стороны, микрсервисы - это именно такие справочники, а не сводное планирование

[trud]

Цитата:

Сообщение от mazzy

Майкрософт так и сделал со сводным планированием. Можно почитать отзывы, посмотреть на результат, так сказать

Ну кстати по поводу сделал - если посмотреть список тех настроек стандартных сводного планирования что не поддерживается этим сервисом, он просто огромен, т.е. сделали какую-то упрощенную модель. Можно посмотреть по словам - not supported и pending
https://docs.microsoft.com/en-us/dyn...n-fit-analysis

Думаю реализовать такой же сервис внутри D365 было бы на порядок проще, плюс работал бы он так же быстро, т.е. основная сложность таких операций, это как раз множественные настройки, каждая из которых резко усложняет систему, вынуждает делать доп. запросы и прочее

Микросервисы это все же про людей, а не про техническую составляющую, вот просто отличное видео, которое раскрывает проблему
https://www.youtube.com/watch?v=gfh-VCTwMw8