Лучшими архитектурами являются те, которые соответствующим образом вписываются в контекст проблемы: каковы драйверы, которые в конечном итоге определяют, как выглядит лучшая архитектура и решение?
Например (ответ на точку Юрия): ваши проблемы могут быть связаны с производительностью и / или управлением данными - оба требуют адресации, но маловероятно, что вы получите одно решение, которое адресовало бы оба, они могут даже быть противоречивыми.
С точки зрения управления данными, я бы предложил вам иметь мастер-копию данных, которая является "правдой". Но это может быть не так хорошо для производительности - конечно, это зависит от подхода.
С точки зрения специфики: я бы начал с данных: смоделируйте их, убедитесь, что вы понимаете их, понимаете текущие потоки данных и как они связаны с бизнес-процессами. Вы хотите перейти к точке, в которой вы можете сказать «это мы делаем, потому что этого требует законный бизнес-процесс» и «мы делаем это из-за технических ограничений, которых у нас не должно быть».
В общем смысле вам нужно:
- Возьмите контекст вашей проблемы в качестве ввода.
- Это поможет сформировать ваши критерии оценки (именно так вы будете оценивать идеи, которые вы придумали).
- Определение начальных вариантов решения высокого уровня / направления. Это дискуссии о голубом небе, которые могут быть относительно свободными от ограничений: мыслить масштабно, мыслить нестандартно Критическим моментом является не начать думать с точки зрения реализации или даже конкретных технологий. Вы также можете ограничить деловые ограничения: «хорошо, мы делаем это, потому что текущий бизнес-процесс - это X, если бы мы сделали Y (используя эту новую технологию), мы могли бы тогда сделать Z и сократить эксплуатационные расходы».
- Просмотрите и оцените по вашим критериям.
- Преследовать логические опции : в основном взять выходные данные 3 и 4 и перевести их на следующий уровень. Вы можете начать думать о шаблонах предприятия / дизайна на этом этапе.
- Просмотрите и оцените по вашим критериям
- Продолжить варианты реализации : вам нужен компонент для "X": вы повторно используете, покупаете или собираете? Есть ли лучшие инструменты породы, которые вы можете использовать? Совместимы ли они с вашей текущей инфраструктурой? И так далее.
- Просмотрите и оцените по вашим критериям.
- Зарегистрировать результат ( причины, по которым ) в Реестре архитектурных решений для дальнейшего использования; это должно / должно включать входы и выходы предыдущих шагов. Идея здесь состоит в том, чтобы помешать людям, которые идут за вами, снова делать всю эту работу - или слепо переписать ваше хорошо продуманное решение плохим.
Обновление: Особенности
- Вы используете репликацию "Multi-Master" - как насчет Master-Slave?
- Вы используете репликацию базы данных - как насчет решения, которое не ориентировано на базу данных?
- Ищите шаблоны проектирования, специфичные для данных и / или распределенных систем; Шаблоны данных выглядит хорошим началом (я сам не читал его, и, возможно, Oracle предлагает аналогичный материал, который может быть более подходящим для специфики вашей платформы).
- Если сайты отключены, можете ли вы заблокировать определенные таблицы / данные, чтобы их нельзя было изменить до тех пор, пока они снова не будут подключены?
- Используйте подход контроля исходных текстов "извлечения", чтобы гарантировать, что изменения данных хорошо контролируются.
- Взгляните на различные подходы кеширования, которые могут дать вам несколько полезных идей, поскольку основная концепция заключается в том, чтобы сохранять локальные копии данных для быстрого доступа, не позволяя им устареть.
- Посмотрите на мультитенантные архитектуры, им часто приходится сталкиваться с разделением данных различными способами и работать в распределенных средах.
Да, я дал общий ответ - но приведенная информация также была довольно общей:)