Service Layer – Domain Logic Patterns (PoEAA)

Паттерн Service Layer определяет для приложения границу и набор допустимых операций с точки зрения взаимодействующих с ним клиентских компонентов. Он инкапсулирует бизнес-логику приложения, управляя транзакциями и управляя ответами в реализации этих операций.

Бизнес-приложения обычно нуждаются в различных интерфейсах к данным, которые они хранят и логике, которую реализуют: загрузчики данных, пользовательские интерфейсы, интеграционные шлюзы и другое. Вопреки различным целям, эти интерфейсы часто нуждаются во взаимодействии с приложением для доступа и управления его данными и исполнения логики. Эти взаимодействия могут быть сложными, использующими транзакции на нескольких ресурсах и управление несколькими ответами на действие. Программирование логики взаимодействия для каждого интерфейса вызовет больше количество дублирования.

Основные соглашения в ходе проектирования Service Layer

• Нейминг. Service Layer должен быть достаточно абстрактным, чтобы его мог использовать любой клиент. Необходимо давать имя службе, понятное и логично для любого обращающегося к ней клиента​.
• Ответственность. Service Layer должен содержать код, выполняющий только задачи связанные с общей обработкой множества объектов. Его можно сравнить с оркестром. В то время код, который относится только к определенному объекту (отдельный музыкант) должен находиться уже в Domain Layer.
• Очередность. Так как несколько клиентов могут выполнить запрос в одно и тоже время, это может привести к ошибкам, особенно что касается работы с базой данных. Service Layer должен уметь обрабатывать такую ситуацию. В лучшем случае должен обеспечиваться сбор всех запросов и их последовательная обработка. Это требование особенно важно в случае оптимизации службы в условиях ограниченного количества SQOL и DML операций.
• Управление транзакциями. Service Layer должен обеспечить сохранность данных при возникновении исключительных ситуаций. Одним из примеров является такая ситуация – вы сохраняете объект A и B в рамках одной транзакции, сохранение объекта B приводит к ошибке, состояние базы данных откатывается на состояние до начала транзакции, но объект A уже будет содержать заполненное поле ID. Это может привести к ошибкам в логике приложения. Как решение можно использоваться объекты-клоны и работать уже с ними. В случае успешной транзакции объекты-клоны становятся оригинальными объектами.
• Конфигурация - у вас могут быть общие конфигурации или поведенческие переопределения на уровне сервиса, например, предоставление контроля, позволяющего клиенту указывать уровню сервера не фиксировать изменения или отправлять электронные письма. Этот сценарий может быть полезен в случаях, когда клиент реализует функцию предварительного просмотра и тд. Обязательно подумайте, как реализовать это последовательно, возможно, в качестве перегрузки метода, которая принимает общий параметр Options.