например, у меня есть таблица пользователя, чтобы быть слоем, я создаю такие POJO:
UserEntity.java
UserDao.java
UserBO.java(бизнес-объект, модель домена?)
UserService.java(для уровня обслуживания)
какая разница между UserBO.java и UserService.java? почему мы разделяем его на два объекта?
Модель домена содержит информацию и функциональные возможности, связанные с тем, что означает быть пользователем. Он должен концептуально отобразиться на нечто, существующее физически в реальном мире или четко определенное понятие в проблемном пространстве.
Служба содержит информацию и функциональные возможности, связанные с выполнением атомных единиц работы. Он должен концептуально отображаться в задачах, выполняемых членами модели домена или их членами. Одна атомная задача, выполняемая нажатием кнопки в приложении, обычно включает в себя много членов домена, работающих вместе, если вы не просто приложение CRUD-y электронного шкафа.
Entity: что-то, что сопоставляется с какой-то сущностью (= объект интереса) в проблемной области. В некоторых случаях (DDD) существуют богатые модели доменов, где сущности имеют методы, которые могут управлять состоянием модели. Более консервативный подход - сделать их анемичными (нет методов, кроме геттеров и сеттеров). Обычно класс Entity попадает в таблицу базы данных.
BO: Я предполагаю, что это какой-то объект передачи данных. Некоторые люди очень обеспокоены ограничением доступа к объектам только в ограниченной части приложения, и им нравится копировать данные из сущностей в DTO. Таким образом, служба может получать объект из DAO, а затем копировать его в DTO и что DTO - это то, что абонент службы может вернуться.
Объект доступа к данным обеспечивает способ запроса или обновления данных, он может иметь методы запросов, которые возвращают объект или коллекцию объектов. Обычно DAO не определяют транзакции базы данных, они позволяют службе делать это.
Служба - это то, что выполняет какую-то задачу, например, различные варианты использования обычно не разбиваются чисто по линиям сущностей. Кроме того, службы обычно включают зависимости, которые сущности пытаются избежать (поскольку модель домена относится к состоянию моделирования и изменениям состояния, а зависимости относятся к инфраструктуре). У службы могут быть методы, которые реализуют варианты использования для некоторого пользователя, где каждый метод является транзакционным.
Возможно, слишком высокий уровень обзора, но вот как я подошел к расслоению раньше, он в значительной степени соответствует вашей традиционной архитектуре N-уровня.
Веб-интерфейс между браузером пользователя и уровнем обслуживания преобразует параметры HTTP в данные, которые вам потребуются.
--- Используйте Business Objects для связи между этими слоями ---
Сервис - интерфейс между вашим веб-уровнем и вашим уровнем DAO, ничего конкретного для протоколов передачи здесь, т.е. нет HTTP-запросов/параметров, бизнес-объектов в вашем случае. Здесь представлена вся ваша бизнес-логика. Например, если ваш веб-уровень говорит "дать разрешение 1 пользователю 1234", ваш уровень обслуживания преобразует разрешение для READ и пользователя 1234 в UserEntity, который возвращает его в БД.
--- Использовать Entities для связи между этими слоями ---
DAO - интерфейс между вашим уровнем обслуживания и фактическим механизмом сохранения, должен быть настолько тупым, насколько это возможно, то есть если предполагается, что объект "покупки" будет иметь объект "пользователь", DAO следует предоставить как, он должен не нужно иметь дело с поиском пользователя, например.
Использование этого разделения между слоями облегчает unit test и поддерживает каждый слой независимо от других. Разработать BO, самое большое преимущество тех, кто получает данные от интерфейсного уровня до уровня обслуживания, инкапсулированного в один объект, и он оставляет поиск фактических записей БД на уровень сервиса. Надеюсь, что это поможет.