Структура програми 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пакетом є технічний поділ , тепер все може отримати доступ до сховища. Бум проходить вашу інкапсуляцію всередині сервісного шару.

Натомість слід дотримуватися більш функціонального підходу, заснованого на цибулі ( чиста архітектура , шестикутна архітектура ). Це також добре відповідає принципу єдиної відповідальності (якщо застосовується до упаковки), а також відповідно до принципів упаковки

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

Тепер ви можете розглянути можливість повторного використання об'єктів зсередини вашого ядра в інші шари, але для IMHO краще використовувати певний домен для цього шару. Так само, як і у відображенні Object to SQL, (часто) є невідповідність того, що ми хочемо показати на екрані або використовувати як XML у веб-сервісі, і як реалізується бізнес-логіка. Залежно від складності бізнес-та веб-доменів, ви можете розглядати їх як окремі проблемні домени, для вирішення яких потрібно підключитись, в основному 2 різних обмежених контексту .

Використовувати цитату з ресурсу CQRS

Неможливо створити оптимальне рішення для пошуку, звітності та обробки транзакцій за допомогою єдиної моделі.

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

Заключна примітка

Пам'ятайте, що створення архітектури вирішує питання про компроміси одного рішення іншого. Це сильно залежить від складності домену і в основному має керуватися функціональними вимогами вашої програми. Однак на це впливають нефункціональні (продуктивність, безпека) та екологічні обмеження (мова для використання, платформа, досвід). І архітектура, як і кодування, ніколи не закінчується, кожна нова вимога може (і, можливо, повинна?) Призвести до оновлення програми.

Відмова від відповідальності

Так, я також намагався скласти все в єдину модель, і так, я також намагався використовувати технічний поділ у своїх програмах. Однак, через пару років досвіду створення заплутаних шарів додатків (спочатку це здається гарною ідеєю, потім додаток починає рости ...) я зрозумів, що повинен бути інший шлях.

Посилання

1. Чиста архітектура, дядько Боб Мартін
2. Шестикутна архітектура (він же Порти та адаптери), Алістер Кокберн
3. Ой, куди поділася моя архітектура, Олівер Гірке
4. Принципи OOD, дядько Боб Мартін
5. Помилки при застосуванні DDD, Уді Дахан
6. Обмежений контекст, Мартін Фаулер
7. Архітектурно очевидний стиль кодування, Саймон Браун

Книги

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