Всем привет. Мне для обзора в  диссертации нужно найти модульные веб-приложения Ruby (лучше Ruby on Rails). Лучше всего подойдут модульные по ядру(например, функциональность распределена между engines и есть какие-нибудь интерфейсы для общения с модулем) или приложения, которые можно обогащать модулями и тоже есть интерфейсы(Redmine).  Из нетривиальных пока нашёл только Redmine. Не могли бы вы мне что-нибудь подсказать?

gitlab, discourse

Не думаю, что оно по описанию подойдёт

В gitlab же много языков  используется, вряд ли подойдет. А Discourse когда-то смотрел или чего там не увидел?

Там монолит на рельсе + го

у нас продукт с engine, но естественно чем-то кроме общей информации я не смогу поделиться)

Мы сейчас именно так и делаем, но показать, увы не получится.
Распиливаем монолит на engine по подприложениям, которые у нас скопились внутри монолита, чтобы потом иметь возможность распилить на отдельные сервисы.
Потому как раз интерфейсный слой делаем, чтобы не общаться напрямую с основным кодом.

Еще у меня очень давно был опыт работы над торговой площадкой, где были подразделы с разными реализациями бизнес-логики.
Были "интерфейсы" типов торгов в основном приложении и engine были разные реализации как бэка, так и фронта (это было очень давно и ни о каких SPA речи не шло).
Основной модуль engine прописывался прямо в базу как поле у торгов и из этого поля бэк понимал какой энжин подгружать и какую логику ющать.

Если чисто руби, можно еще Fastlane посмотреть, он прикольно сделан как раз из кирпичей, но не совсем стандартное приложение.

А есть какой-то профит от усложнения такого взаимодейтсвия engine - интерфейс - application? Мы просто думали над тем чтобы разбить на микросервисы, оценили, что это очень много работы и усложнения архитектуры. Начали бизнес логику просто распределять по engine, но связность очень сильная, если нужно напрямую обращаемся к моделям app.

Ближе к моей проблемы распределение по функциональности. Т.е. один модуль engine для поддержки пользователей, другой  engine для опросов и отчетов. И Каждому из них иногда нужно URL прописать  для ресурса из другого модуля или аж has_many свзязь установить с моделью  из другого модуля.

А можешь скинуть ссылку?

Как раз выше написал про это. Но вот такие случаи, как с has_many у меня в engines редко. Модули сильно связны внутри и слабо снаружи, но вот бывает такое.

А у нас выбора нет с таким монолитом комфортно жить, нам нужны разные релизные циклы для каждого из этих приложений. И разные требования по скалированию.
Но взять и махом перейти сразу на микросервисы мы не готовы, у нас все очень плотно переплетено.

Так что как раз чтобы снизить связность мы и начали делить на engine.

И внутри engine мы не обращаемся к моделям из основного приложения, а дублируем их, иначе смысла мало выходит.

Вот дублировать модели вообще звучит не очень,  как по мне

Евгений тут рассказывает как у него переходят на engine, а у нас наоброт происходит внос engine в монолит)))

За дискорс спасибо, действительно что-то в нем есть

А по-моему это как раз основной плюс. Мы вот как раз перешли на entity+repository вместо жирной модели.

Я тоже как-то не схватил идею про дублирование. Если не разъезжаться по микросервисами, то не вижу в этом смысла