Когда объединять несколько приложений, чтобы упростить интеграцию их данных?

Я поместил это в отдельный ответ, так как его фокус сильно отличается от моего первого.

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

Как бы вы решили...

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

• Составьте список соответствующих ограничений.
• Перечислите результаты, которые вам не нужны (одно большое неуправляемое приложение и т. д.).
• Также рекомендуется, но, возможно, не обязательно: Определите риски и потенциальные воздействия (как часть ограничений или нежелательных результатов).
• Перечислите желаемые результаты (совместное использование данных, простое развертывание и т. д.).
• Расставьте приоритеты между желательными и нежелательными результатами (очень важно) и не удивляйтесь, если они изменятся в ходе дебатов.

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

Есть также некоторые дополнительные вещи, которые вы можете сделать перед этим семинаром (или как его часть, в зависимости от политической и социальной динамики вашей ситуации).

• Определите цели системы — как в «деловом», так и в «архитектурном» смысле. (подсказка: они должны совпадать или, по крайней мере, не конфликтовать).
• Если для системы или вашего бизнеса есть четкое видение, которое должно помочь (но имейте в виду, что они не всегда существуют, а хорошие еще реже).
• Обратитесь к бизнес-/стратегическим планам систем, над которыми вы работаете, и примите во внимание рынок, тенденции и т. д. Что, по вашему мнению, может произойти с приложениями в будущем? Думать заранее с точки зрения архитектуры это не то же самое, что YAGNI на уровне кода, и тщательное рассмотрение будущего может повлиять на решения, которые вы принимаете сейчас.

Здравствуйте! Не уверен, что освещаю именно те вопросы, на которые вы хотите получить ответы, но это только начало. попросите разъяснений, если хотите, и я соответствующим образом обновлю свой ответ.

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

Что касается интеграции, повторное использование зависит от нефункциональных требований различных систем. Единая общая служба упрощает управление данными (в том смысле, что нужно беспокоиться только об одной копии), но это означает, что она может стать узким местом; кроме того, применяется правило «самого слабого звена в цепочке» — каковы будут последствия, если общий сервис выйдет из строя?

Возможные варианты решения

Трудно понять, что порекомендовать без дополнительной информации, но мои мысли таковы:

• Держите свои три приложения отдельно.
• Используйте единую общую службу для общих данных.
• Доступ к общим данным может осуществляться через «службу» — это даст вам максимальный контроль и возможности.
• Общая служба может существовать как один экземпляр или у вас может быть развернуто несколько экземпляров службы (но только один экземпляр БД).

Ключевым моментом является то, что вы должны иметь возможность абстрагироваться от общего сервиса, не затрагивая другие приложения — в частности, вам не следует думать о создании приложения uber.

И еще один момент: мысль о том, что существует одна «услуга» в деловом смысле, не исключает наличия нескольких способов ее технического раскрытия и использования.

Думали ли вы о параллелизме, транзакциях,...

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