Maven мультимодульный вырез

Question

Мы используем многомодульные проекты для компонентов нашего программного обеспечения. Подмодули распространяются на API и реализации . Преимущество состоит в том, что другие проекты maven могут импортировать только часть API и не видят реализующие классы.

Это лучшая практика? Он не очень мелкозернистый, что в итоге может привести к большим пакетам. Мне больше нравится многоуровневый подход, который будет означать такие модули, как client , logic , persistence Каждый из них может иметь отдельный модуль api и реализация . Будет ли это слишком много, потому что это означает наличие 6 модулей вместо 2?

Answer 1

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

Если в каком-то модуле начинает дублироваться код (например, в jdbc / orm), мы добавляем новый «технологический» модуль, абсолютно не зная о нашем бизнесе (в отличие от уровня постоянства), и импортируем его вперсистентный слой модулей, которым он требуется.

Answer 2

6 модулей не должно быть проблемой. Я работаю над проектом с более чем 50 модулями без проблем, вызванных количеством модулей.

Изменение области видимости и зависимостей между модулями может немного сбить с толку и сделать это намного проще (но не просто), когда вы используете только пакет java плюс правило для разрешенных зависимостей, внедряемых таким инструментом, как JDepend или Structure101.

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

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

Answer 3

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

Я не вижу никакой причины пытаться сохранить количество модулей небольшим; это просто структура, которая введена, чтобы прояснить, что происходит, и определить, что может с чем взаимодействовать. У вас может быть даже несколько модулей, которые можно использовать в определенных ролях, чтобы вы могли (например) поддерживать причуды конкретных баз данных на вашем уровне персистентности, с которыми модули фактически используются, в зависимости от того, какой профиль Maven используется. (В моем коде я использую это, чтобы отделить несколько специфичных для платформы частей кода от подавляющего большинства независимых от платформы частей.)

Answer 4

Непонятно, зачем вам экспортировать API со всех уровней вашего приложения. Обычно в трехуровневой структуре GUI -> Service -> DAO (это аналогично вашему клиенту -> Logic -> Persistence?), Вы можете экспортировать слой Service как программный API для других приложений, но, вероятно, GUI будет быть слишком привязанным к реализации, чтобы иметь отдельный API.