Я не скажу, что есть абсолютно правильный способ сделать это.
Если ваше приложение довольно простое, например, просто операции с базой данных для создания и извлечения данных, простая модель данных и без сложной бизнес-логики, тогда может быть хорошо использовать тот же DTO. Этот сценарий в основном не соответствует действительности.
Но если ожидается, что ваше приложение будет обрабатывать значительный набор бизнес-прецедентов, рекомендуется отделять объекты уровня вашего основного домена от тех, которые используются для взаимодействия с внешней системой, такой как API или очередь сообщений.
Если вы возьмете пример (немного надуманный вариант использования, чтобы выявить то, что я делаю):
Предположим, что пользователи могут создавать клиентов в вашем приложении через конечную точку ReST, и существует четко определенная модель запроса:
class CustomerDTO {
private String firstName;
private String lastName;
private String companyId;
private String email;
private List<String> subscriptions; // customers subscribe to services
}
Предположим, модель вашего домена:
class CustomerBO {
private String name; // firstName + lastName
private String companyId;
private String email;
private List<String> subscriptions; // customers subscribe to services
}
Позже, если вы хотите добавить возможность создавать сущности, читая их из очереди сообщений или файла CSV - ваше приложение может быть нисходящей системой, получающей канал из другого приложения. В этом случае у вас есть следующие отличия от варианта использования API:
- каждый клиент имеет только 1 подписку (всегда)
- имя отправляется одним полем
- электронной почты нет, поскольку эти клиенты не являются настоящими пользователями (то есть, не нужно отправлять электронные письма, входить в систему и т. Д.)
Итак, ваша модель запроса выглядит так:
class FeedCustomerDTO {
private String name;
private String companyId;
private String subscriptionId;
}
Теперь ядро приложения просто принимает CustomerBO. Модули API и Feed преобразуют модели запросов в согласованную модель предметной области. Вы можете видеть, что наличие согласованного CustomerBO для этих двух вариантов использования помогает поддерживать чистоту ядра вашего приложения и от взаимодействия с ним.
Надеюсь, что это имеет смысл и отвечает на ваш запрос.