На основе ADR-001 (не существует, про выбор архитектурного стиля проекта) было решено использовать микросервисы. Отсев лучших кандидатов является отдельным bounded context и теоретически может быть вынесен в отдельный сервис.
Основные консёрны, связанные с вопросом:
- Технические характеристики elasticity и availability уникальны для системы
- Топ-менеджмент хочет релизить эту часть чаще, поэтому потребуются изменения в CI/CD процессе, необходимые исключительно для одного контекста. Да и передеплоивать всю систему лишний раз никому не хочется
- Топ-менеджмент имеет планы на продажу системы скоринга как отдельного продукта
- Подбор кандидатов является core поддоменом, а значит отличительной частью системы. Большинству уникальных особенностей свойственно часто изменяться, пока не будет найдена "работающая" комбинация.
Для решения вопроса были проанализированы консёрны и выделены следующие заключения:
- Не имеет смысла изменять приведенные выше характеристики для всей системы, жертвуя значениями других важных характеристик
- Безопаснее и быстрее проверять гипотезы в отдельном сервисе, который проще откатить в случае неудачи
- Менеджмент не обозначил сроки выполнения своих задумок по продаже скоринга как отдельного продукта, но в дальнейшем отдельный сервис гораздо проще "отрезать" от системы
На основе проведенного исследования принято решение вынести bounded context "Отсева лучших кандидатов" в отдельный сервис.
Незначительно повышается число коммуникаций с другими сервисами, а значит и coupling.