Структура приложения Java: горизонтальное или вертикальное разделение

Немного поспорил о начальной структуре проекта (используя Maven / Eclipse) для большого Java-приложения.

Опция 1:

entities (i.e. the whole database using Hibernate classes-first)
services (i.e. sets of read/write operations on the entities)
app (perhaps split up more further down the line)

Вариант 2:

area1-entities
area1-services
area1-app
area2-entities
area2-services
area2-app
...
(where area1, area2 etc. are functional areas of the system)

Вариант 2 явно приведет к большему количеству проектов / модулей Maven и означает, что классы, которые будут генерировать базу данных, распределены по нескольким проектам. Кто-нибудь может посоветовать плюсы / минусы каждого подхода?

Я бы предложил не делать ни того, ни другого.

Попытка навязать технический уровень со структурой пакета приводит к значительному запутыванию в вашем приложении. Не говоря уже о том, что мы так стараемся скрыть все за интерфейсом сервиса, и первое, что мы делаем (в основном из-за упаковки), это делаем все public class. Это становится болезненным, когда есть техническое разделение между a x.y.z.serviceи x.y.z.repositoryпакетом, теперь все могут получить доступ к хранилищу. Boom, там идет ваша инкапсуляция внутри уровня обслуживания.

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

1. Вещи, которые меняются вместе, упакованы вместе
2. Вещи, которые используются вместе, упакованы вместе

Оливер Гирке написал замечательную статью об объединении компонентов в Java. Саймон Браун написал более общую историю на эту тему.

Я бы стремился к структуре базового пакета, подобного следующему, чтобы сохранить ядро ​​вашего приложения:

x.y.z.area1
x.y.z.area2

Теперь, если у вас есть веб-интерфейс, вы добавляете, например, webподпакет, для веб- сервиса a wsили restпакета, в котором хранится только это. Это в основном подключается к ядру.

x.y.z.area1.web
x.y.z.area1.ws
x.y.z.area2.rest

Теперь вы можете рассмотреть возможность повторного использования объектов из вашего ядра в других слоях, но имхо лучше использовать определенный домен для этого слоя. Так же, как и при сопоставлении объекта с SQL, (часто) имеется несоответствие в том, что мы хотим показать на экране или использовать в качестве XML в веб-сервисе, и в том, как реализована бизнес-логика. В зависимости от сложности бизнеса и веб-доменов вы можете рассматривать их как отдельные проблемные домены, для решения которых необходимо подключиться, в основном это два разных ограниченных контекста .

Чтобы использовать цитату из ресурса CQRS

Невозможно создать оптимальное решение для поиска, составления отчетов и обработки транзакций с использованием единой модели.

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

Финальная нота

Помните, что создание архитектуры - это выбор компромисса одного решения другому. Это сильно зависит от сложности домена и должно в основном зависеть от функциональных требований вашего приложения. Однако на это влияют нефункциональные (производительность, безопасность) и ограничения среды (язык, платформа, опыт). А архитектура, как и кодирование, никогда не заканчивается, каждое новое требование может (и может быть должно?) Привести к изменению дизайна приложения.

отказ

Да, я также пытался поместить все в одну модель, и да, я также пытался использовать техническое разделение в своих приложениях. Однако после нескольких лет опыта в создании запутанных слоев приложений (сначала это кажется хорошей идеей, затем приложение начинает расти ...), я подумал, что должен быть другой путь.

связи

1. Чистая архитектура, дядя Боб Мартин
2. Шестиугольная Архитектура (иначе Порты и Адаптеры), Алистер Кокберн
3. К сожалению, где моя архитектура пошла, Оливер Gierke
4. Принципы ООД, дядя Боб Мартин
5. Ошибки при применении DDD, Udi Dahan
6. Ограниченные контексты, Мартин Фаулер
7. Архитектурно очевидный стиль кодирования, Саймон Браун

книги

1. Растущее объектно-ориентированное программное обеспечение, ориентированное на тесты
2. Архитектура приложения Java: шаблоны модульности с примерами с использованием OSGi (серия Роберта С. Мартина)
3. Проектирование на основе доменов: борьба со сложностями в основе программного обеспечения
4. Архитектура программного обеспечения для разработчиков
5. Реализация доменного дизайна