Подходящая архитектура для переписывания с интеграцией + сценарий миграции

Question

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

У нас есть 3-4 устаревшие системы, которые абсолютно не могут быть адаптированы к новым прецедентам из-за ужасающего кода, но по-прежнему обрабатывают довольно большое количество заказов в день через различные интерфейсы и форматы, такие как электронная почта, xmlrpc, webinterface.

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

Идея состояла в том, чтобы полностью перепроектировать всю модель домена с нуля, создать заказ-сервис и использовать Apache Camel с контейнером OSGi, чтобы имитировать старые интерфейсы, маршрутизирующие заказы на устаревшие и новые системы, и отделить формат обрабатывать и транспортировать себя из новой системы. Из-за постепенного развития мы хотели бы выбрать более «ориентированную на обслуживание» архитектуру, которая позволит нам постепенно улучшать, повторно использовать и масштабируемость. Все это звучит неплохо на бумаге, и я немного читал о «SOA», но до тех пор, пока не ожидал, что реклама уйдет и «хорошие» части останутся, но большая часть разговоров по-прежнему остается очень абстрактной и неточной «технической уровень продаж ".

Я нахожу подход «Базовая/общая служба данных» довольно проблематичным, если у меня есть сущности с большим количеством отношений, таких как порядок, с довольно большим графиком. Если бы я создал отдельную службу для операций CRUD в Orders и других объектах, чтобы основать более абстрактные, было бы действительно проблематично или невозможно обрабатывать ACID, реляционную целостность или вам пришлось бы пожертвовать автономией этих сервисов и соединиться их, что сделало бы сервисы совершенно бесполезными (и, возможно, довольно медленными). Или я понял что-то не так?

Итак, моя идея состояла в том, чтобы просто создать «традиционный» DAL, используя приятные JPA POJO, конечно же с интерфейсами, и развернуть его как простой пакет OSGi с версией для используемых бизнес-процессов и процессов, иметь более абстрактное сопоставление , Затем эти службы просто используют его и выставляют свой интерфейс на шину. Чтобы обслуживать редкий случай необходимости доступа к отдельным данным, например, для обогащения контента при импорте верблюдов или массовых данных или отчетов, может быть создано уродливое «все объекты, включенные в сервис», что позволило бы решить проблему с ACID и целостностью.

До сих пор так хорошо, НО: как должен WebUI (который в основном CRUD, как я упоминал и, тем самым, не совсем абстрактный процесс), получить доступ к данным? Непосредственно использование JPA POJO сделало бы его достаточно сложным, но создав карту и представив другую, почти идентичную модель и использующую вышеупомянутую «службу DAL-монстра», тоже не слишком хорошо звучит.

Как вы думаете? Где хороший баланс между чувством, элегантностью и практичностью?

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

Спасибо за ваше время :)

Answer 1

Это не столько ответа, как записки, желающего вам хорошее состояние.

У нас есть ситуация, которая является той же самой/другой формой вашей, и она оказывается очень сложной задачей для эффективного решения.

Я думаю, что ваш подход в порядке, кажется, что вы поражаете баланс OK.

Вы можете использовать шаблоны интеграции предприятия, такие как published by Martin Fowler, но может ли это доставить вас туда, где вы хотите/должны оставаться, еще не видно.

Другие варианты: есть машина «колбаса»: вы нажимаете старую систему в систему, которая генерирует «новый» код (на Java или .Net), который становится вашей новой платформой. хорошо, что у вас теперь есть кодовая база на языке, с которым вы можете работать, плохая новость в том, что это будет самая большая самая ужасная куча спагетти, которую вы когда-либо себе представляли.

Даже тогда это огромное предприятие. Государственное агентство здесь потратило 2 или 3 года и 5 миллионов долларов, чтобы это сделать. Это было не красиво или безболезненно, но, похоже, сработало. Если вы спросите об этом достаточно (то есть: не на StackOverflow), вы должны найти людей, которые справились с переходом с платформ, за которыми вы застряли, поговорите с ними.