Приложение для крупных предприятий Java - модуляция

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

Наша основная система основана на веб-интерфейсе, включая webservices. В настоящее время мы перепроектируем весь проект и намечаем момент для начала структуры проекта.

У нас есть 7 веб-модулей, включая веб-проект на основе Struts2 и Spring 3.1. Ядро Webservice на основе JAX-WS и Spring 3.1

Мой вопрос - вот что такое лучшие практики для проектирования структуры проекта и модуляции для такого проекта:

Мы обязательно будем использовать Maven и OSGi, если это необходимо. Я думаю в чем-то вроде

WebProject.war
   |---Web.xml
   |--- Libs
   |
   |--- Web Module1.jar
   |--- Web Module2.jar
   |--- Web Module3.jar
   |--- Web Module4.jar
   |--- Web Module5.jar
   |--- Web Module6.jar

 WebService.war
   |---Web.xml
   |--- Libs
   |
   |--- Service.jar
   |--- Service2.jar

 EJBProject.jar
   |
   |--- module.jar
   |--- module2.jar

Это то, что я лично имею в виду, но мы ищем что-то более модульное, чтобы мы могли работать и развертывать WebModule1.jar, не затрагивая другие модули и основной проект WebProject.war. Кроме того, мы хотим, чтобы специализированные команды имели только код своих проектов, поэтому, если команда должна работать только с Service2.jar в своем IDE, у них будет только код для Service2.jar и ресурсный проект с другими проект уже скомпилирован.

Спасибо

ОТВЕТЫ

Ответ 1

Ключевым аспектом модульности является то, что ваш модуль знает так мало, насколько это возможно по-человечески, чтобы его можно было повторно использовать во многих разных контекстах. Ошибки возникают только тогда, когда допущение нарушается, минимизируя предположения, является самым большим убийцей ошибок. OSGi предоставляет такие инструменты, как μservices, которые очень хороши, позволяя предположениям оставаться локальными.

Ваш макет очень похож на веб-проект, который imho ошибочен, так как большинство кода, который мы должны развивать, должны быть независимы от технологии, используемой для его представления. Вся эта технология, скорее всего, изменится в ближайшем будущем, так как веб-приложения быстро переходят в браузер, браузеры снова становятся толстыми клиентами. То есть очень современные интерфейсы REST уже очень старомодны, если вы видите, что делает чистая передача сообщений. Вся эта волатильность означает, что вы хотите сделать ваши модули максимально возможными.

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

Ответ 2

Я очень рекомендую читать Kirk Knoernschild "Архитектура приложений Java: Шаблоны модульности с примерами с использованием OSGi" . Вы можете начать с модуляции приложения до перехода на OSGi (и я определенно буду вкладывать средства в хорошее тестовое покрытие, если у вас его еще нет).

Если вы используете сервлет 3.0, посмотрите на веб-фрагменты.

С точки зрения структуры, которую вы показали, я бы сказал, что ничего не гнездятся (кроме веб-фрагментов), WAR могут стать WAB (пакет веб-приложений - в основном тощая WAR). Также используйте OSGi μServices как можно больше - то, где начинается забава =)

Рамки OSGi для предприятий, такие как Karaf и Virgo, предлагают большую поддержку, в то время как вы разделяете разделение JEE-OSGi (Equinox и Felix сами по себе немного босики).

Ответ 3

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

  • Spring/Struts/CXF/и т.д.. maven артефакты,
  • WAR/JAR/и т.д.. плагины,
  • Серверы приложений развертывают/тестируют плагины и т.д.
  • И вы можете предоставить только общие артефакты maven для команд, которые разрабатывают только определенные модули без совместного использования всей кодовой базы.
  • Maven поддерживается всеми серверами непрерывной интеграции (Hudson/TeamCity и т.д.).

OSGi. Если вы хотите его использовать, вам нужно внимательно изучить ваш текущий дизайн и попытаться адаптировать его к μServices. В общем, у вас будут модули с API, пользователями API и поставщиками API. Это помогает вам разделить развитие между командами (например, один разрабатывает пользовательский модуль API, другой - модуль поставщика API). Если вам нужно, вы можете разделить API-интерфейс потребителя/поставщика на 2+ пакета OSGi (которые являются модулями Maven).

Ответ 4

Ваша структура выглядит хорошо для меня, что является типичной структурой для большинства проектов - одна рекомендация, которую я бы дал, - это версия ваших зависимостей, поэтому, например, пусть ваш webproject.war зависит от webmodule1-1.3, скажем, таким образом потенциально разные конечные проекты могут иметь разные версии зависимых банок.

Использование maven определенно упростит управление этими зависимостями

Если ваши требования заменяют зависимости во время выполнения, то да, вам придется идти на такие технологии, как OSGI, однако, если это не модульная система времени выполнения, которую вы ищете, я бы рекомендовал не начинать с OSGi и поддерживать проще.

Ответ 5

Немного поработав с OSGi и получив некоторую боль, мы разработали osgi-less модульность для Spring https://github.com/griddynamics/banshun. Wellcome!