Новое веб-приложение intellij / maven, советы по разделению модулей для сервиса, дао, общие библиотеки и т. Д.

Question

Итак, я создал новое веб-приложение на основе maven pom, используя intelliJ 11.

Теперь я хочу выделить различные слои приложения, поэтому у меня сейчас есть:

/myproj
/myproj-common (maven module)
/myproj-services (maven module)
/src/main/webapp  (spring mvc application)

Поэтому я использую следующее:

spring mvc
hibernate

Итак, я создам Дао для каждой сущности, а затем сервисный слой, который будет использовать Дао и обернуть другую бизнес-логику и т. Д.

Как правильно настроить модули maven, не усложняя их?

Должен ли я создать отдельный интерфейсный модуль, который будут использовать мои другие модули?

Нужны некоторые практические советы.

Я использую Maven, чтобы построить это тоже.

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

Обновление

Должен ли я иметь отдельный модуль для моих сущностей?

Answer 1

Самый простой способ - использовать только один модуль maven и выполнять разделение на уровне пакета.

Если вам нужно больше, я могу порекомендовать эту настройку:

myproj-services - классы сущностей, сервисные интерфейсы myproj-services-impl - реализация dao и сервисов myproj-ui - твой весенний урок мвк

Интерфейс пользователя зависит только от сервисов, а сервисы - только от сервисов.

Answer 2

Чтобы ответить на ваше обновление: ИМО да. Чтобы следовать DDD, у вас должен быть модельный модуль, содержащий ваши организации и DAO, а также сервисный модуль для ваших услуг.

Еще один шаг - это разделение служебного модуля на модуль service-api (интерфейсы служб) и модуль service-lib (реализации). Это также влечет за собой то, что вы не передаете сущности из вашего сервисного модуля в ваши веб-модули с помощью TO (или просматриваете, если хотите).

Еще один связанный совет: если вы боитесь, что ваши классы обслуживания станут слишком большими (следовательно, их трудно читать / поддерживать / тестировать), рассмотрите возможность их разделения на бизнес-объекты. Таким образом, вместо UserService, содержащего весь код, у вас есть UserServiceFacade, который делегирует MakeUserBO, FindUserBO, .... Эти BO отвечают за одну (или более, если связаны) задачи и могут быть легко использованы другими службами или другими BO. BO короткие, точные и поэтому легко читаемые / поддерживаемые. Также легче высмеивать определенные BO, пока вы тестируете другие.