Где поместить бизнес-логику в DDD
Я пытаюсь найти лучший способ построить легко ремонтируемую и тестируемую архитектуру. Пройдя через несколько проектов, я увидел несколько довольно плохих архитектур, и я хочу избежать будущих ошибок в своих собственных проектах.
предположим, я создаю довольно сложное трехслойное приложение, и я хочу использовать DDD. Мой вопрос в том, где я должен разместить свою бизнес-логику? Некоторые люди говорят, что он должен быть помещен в службы (уровень обслуживания), и это делает чувство. Иметь несколько обслуживаний которые придерживаются к одиночному принципу ответственности имеет смысл.
однако некоторые люди сказали, что это анти-шаблон и что бизнес-логика не должна реализовываться на уровне сервиса. Почему так?
Допустим, у нас есть IAuthenticationService который имеет метод с bool UsernameAvailable(string username) подпись. Метод будет реализовывать всю необходимую логику, чтобы проверить, доступно ли имя пользователя или нет.
что проблема здесь согласно "это антипаттерн" толпы?
2 ответов
слой сервиса сам по себе не является анти-шаблоном, это очень разумное место для размещения определенных элементов вашей бизнес-логики. Тем не менее, вам нужно применить дискреционное право к дизайну уровня сервиса, гарантируя, что вы не крадете бизнес-логику из модели домена и объектов, которые ее составляют.
сделав это, вы можете получить истинный анти-шаблон, анемичную модель домена. Это подробно обсуждается Мартином Фаулером здесь.
ваш пример IAuthenticationService, возможно, не лучший для обсуждения проблемы - большая часть логики вокруг аутентификации может рассматриваться как живущая в службе и не связанная с объектами домена. Лучшим примером может быть, если у вас есть какой-то IUserValidationService для проверки пользователя или, что еще хуже, служба, которая делает что - то вроде заказов на обработку-служба проверки удаляет логику из объекта пользователя и заказа служба обработки забирает логику из ваших объектов заказа, а возможно, и из объектов, представляющих клиентов, уведомлений о доставке и т. д...
Если вы помещаете всю свою бизнес-логику в уровень сервиса (неявно без состояния), вы пишете процедурный код. Отделяя поведение от данных, вы отказываетесь от написания объектно-ориентированного кода.
Это не всегда плохо: это просто, и если у вас простая бизнес-логика, нет причин инвестировать в полноценный объектно-ориентированный модель предметной области.
чем сложнее бизнес-логика (и чем больше домен), тем быстрее процессуальный код превращается в спагетти-код: процедуры начинают вызывать друг друга с разными пред - и пост-условиями (в несовместимом порядке), и они начинают требовать постоянно растущих объектов состояния.
статья Мартина Фаулера о моделях анемических доменов вероятно, лучшая отправная точка для понимания того, почему (и при каких условиях) люди возражают против размещения бизнес-логики на уровне сервиса.