Недавно мы начали проект в компании, в которой я работаю, для реструктуризации и переписывания системного ландшафта и спасения будущего наших детей.
У нас есть 3-4 унаследованных системы, которые абсолютно не могут быть адаптированы к новым сценариям использования из-за ужасающего кода, но по-прежнему обрабатывают довольно большое количество заказов в день через различные интерфейсы и форматы, такие как электронная почта, xmlrpc, веб-интерфейс.
Поэтому мы подумали о создании новой системы с нуля на основе полностью переработанной модели предметной области. Поскольку мы не можем просто отключить старые системы и являемся действительно небольшой командой, мы пришли к выводу, что нам нужна архитектура и подход, которые позволят нам постепенно разрабатывать новую систему и запускать ее части в жизнь и легко (читай; быстро) интегрировать новые интерфейсы, партнеров и с устаревшими приложениями и интерфейсами.
Идея заключалась в том, чтобы полностью перестроить всю модель домена с нуля, создать Order-сервис и использовать Apache Camel с контейнером OSGi для имитации старых интерфейсов, перенаправляющих заказы в унаследованные и новые системы, и отделить обработку форматов. и транспортировать себя из новой системы. Из-за постепенного развития мы хотели бы выбрать более «сервис-ориентированную» архитектуру, которая позволит нам постепенно улучшать, повторно использовать и масштабировать. Все это звучит хорошо на бумаге, и я довольно много читал о «SOA», но пока не дождался, пока шумиха не утихнет, а «хорошие части» останутся, но большая часть разговоров все еще остается очень абстрактной и неточной. уровень продаж, кажется.
Мне кажется, что подход «Базовая / Общая служба данных» довольно проблематичен, если у меня есть сущности с большим количеством отношений, таких как порядок, с довольно большим графиком. Если бы я создал отдельную службу для операций CRUD с заказами и другими объектами, на которой основывались бы более абстрактные задачи, было бы действительно проблематичным или невозможным обрабатывать ACID, целостность отношений или вам пришлось бы пожертвовать автономностью этих служб и подключиться друг к другу. их, что сделало бы сервисы совершенно бесполезными (и, возможно, довольно медленными). Или я что-то не так понял?
Таким образом, моя идея состояла в том, чтобы просто создать «традиционный» DAL с использованием хороших JPA POJO, конечно же, с интерфейсами, и развернуть его в виде простого, версионного пакета OSGi для использования бизнес-сервисами и сервисами процессов с более абстрактным отображением. Эти службы затем просто использовали бы его и выставляли свой интерфейс на шину. Чтобы удовлетворить редкий случай необходимости доступа к отдельным данным, например, для обогащения контента при импорте верблюдов или массовых данных или составлении отчетов, можно создать некрасивую «услугу, включающую все объекты», которая решит проблему ACID и целостности.
Пока все хорошо, НО: как WebUI (который, как я уже упоминал, в основном CRUD и, следовательно, не совсем абстрактный процесс), получает доступ к данным? Непосредственное использование JPA POJO сделало бы его довольно тесным, но создание картографии и внедрение другой, почти идентичной модели и использование вышеупомянутой «службы DAL» для монстров тоже не слишком хорошо звучат.
Что ты думаешь? Где хороший баланс между чувством, элегантностью и практичностью?
Я сожалею, что это несколько вопросов, а текст довольно длинный, но я чувствовал, что важно изобразить ситуацию, с которой мы здесь сталкиваемся, более подробно.
Спасибо, что уделили время:)