Правильная архитектура приложения с использованием Spring Data
Как правильно спроектировать Spring приложение для работы с этими сущностями, используя entity-repository-service-controller-dto?
У меня получается так:
Entities: Trip, Company, Passenger, PassInTrip
Repositories: TripRepository, CompanyRepository, PassengerRepository, PassInTripRepository
DTOs: TripDto, CompanyDto, PassengerDto
Дальше уже возникают вопросы. Как я знаю, в сервисах должна описываться бизнес-логика.
Services:
CompanyService (getCompanyByName, createCompany, deleteCompany, addTripToCompany, getAllCompanies) PassengerService (getPassengerByPassportNumber, createPassenger, updatePassenger, deletePassenger, addPassengerToTrip)
Выделил курсивом методы, которые вызывают сомнения. PassengerService использует два репозитория - TripRepository и PassengerRepository. Возникает ощущение, что с точки зрения архитектуры это плохое решение и всё должно быть не так.
Контроллера тоже получилось два, вот все эндпоинты:
GET /api/passengers - get list of all passengers
GET /api/passengers/{passportNumber} - get passenger by passport number
POST /api/passengers/create - create new passenger
PUT /api/passengers/update/{passportNumber} - update passenger by passport number
PUT /api/passengers/addToTrip/{passportNumber} - add passenger with given passport number to trip
DELETE /api/passengers/delete/{passportNumber} - delete passenger by passport number
GET /api/companies - get list of all companies
GET /api/companies/{name} - get company by name
POST /api/companies/create - create new company
POST /api/companies/{name}/addTrip - add new trip to company with given name
DELETE /api/companies/delete/{name} - delete company by name
Собственно, вопрос в том, что тут не так с точки зрения архитектуры и как правильно это исправить?
Ответы (1 шт):
Есть принцип единственной ответственности (single-responsibility principle, SRP) и он говорит, что объект должен иметь одну ответственность. У вас есть сервис управления компаниями (CompanyService), сервис управления пассажирами (PassengerService) и сторонний функционал, который вы размазали по ним.
Теперь допустим, что требования расширились и добавилось еще пару функций: бронирование путешествия, поиск по дате, поиск по месту назначения и отправления. Куда вы засунете эти функции и как человек не знакомый с архитектурой, с первого взгляда должен понять, куда их поместить или где ему искать эти функции - мало ли они уже реализованы были?
Ну и ваш вопрос основан на мнениях. Как мне кажется, вам не хватает сервиса регистрации пассажиров (RegistationService) и сервиса управления направлениями путешествий (TripService).