Почему вы подразделяете на maven-модули для собственных проектов?

Question

В нашем проекте постоянно обсуждается гранулярность наших модулей maven. Мы пришли к выводу, что могут быть различия в потребностях фреймворка (например, Spring) и внутреннего приложения, которое всегда монолитно разворачивается.

Мы также согласны с тем, что довольно разумно скрывать детали реализации адаптеров для внешних систем за отдельным модулем API, чтобы классы реализации не попадали в путь к классам основных реализаций. как Но это так далеко, как мы идем. Это веб-проект, поэтому у нас есть такие модули, как «сеть», «ядро» и «адаптер (ы)». У нас есть несколько бэкэндов, но нам не требуется возможность подключения.

Какие критерии вы используете для модульности в Maven? Какие модули вы делаете для веб-проектов?

Answer 1

На мой взгляд, разделение проекта должно быть довольно мелкозернистым, даже для "только веб-приложения".

Я бы сделал отдельные проекты для интерфейсов и реализации уровня доступа к данным, интерфейсов и реализации бизнес-уровня и самого веб-приложения. Я также хотел бы сделать по крайней мере один «общий» проект для содержания кода, относящегося к нескольким другим проектам. Но это только начало. Я без колебаний извлеку проект commons-util для классов утилит, соответствующих независимо от разрабатываемого приложения (String, Date, Reflection и т. Д.). Я бы также сделал проект для полезных утилит при тестировании (commons-test). И это только следующий шаг ...;)

Если бы я написал в целом полезный код, относящийся к hibernate, я бы поместил его в проект hibernate-utils. Полезные утилиты Spring будут включены в проект spring-utils и т. Д. При этом многие проекты содержат только один или несколько пакетов, а пакеты обычно содержат несколько классов.

Я считаю, что это помогает мне думать о коде, который я пишу. Это ДЕЙСТВИТЕЛЬНО бизнес-логика, или это общая обработка строк, манипулирование датами, специфичная логика Hibernate и т. Д.? Мои слои становятся чище, и становится сложнее получать круговые зависимости между пакетами и проектами (мы не хотим их). Кроме того, становится намного проще повторно использовать код в других проектах. Всегда будут другие проекты ...

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

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