Где поставить бизнес логику в DDD

Question

Я пытаюсь найти лучший способ построения легко обслуживаемой и тестируемой архитектуры. Пройдя несколько проектов, я увидел несколько довольно плохих архитектур и хочу избежать будущих ошибок в своих проектах.

Допустим, я создаю довольно сложное трехслойное приложение и хочу использовать DDD. У меня вопрос, где я должен разместить свою бизнес-логику? Некоторые люди говорят, что это должно быть помещено в сервисы (сервисный уровень), и это имеет смысл. Имеет ряд услуг, которые соответствуют принципу единой ответственности.

Однако некоторые люди говорили, что это анти-паттерн и что бизнес-логика не должна быть реализована на уровне сервиса. Почему это?

Допустим, у нас есть IAuthenticationService, у которого есть метод с bool UsernameAvailable(string username) подписью. Метод реализует всю необходимую логику, чтобы проверить, доступно ли имя пользователя или нет.

В чем здесь проблема с толпой «это антипаттерн»?

Answer 1

Если вы помещаете всю свою бизнес-логику в (неявно сохраняющий состояние) уровень обслуживания, вы пишете процедурный код.Разъединяя поведение с данными, вы отказываетесь от написания объектно-ориентированного кода.

Это не всегда плохо: это просто, и если у вас простая бизнес-логика, нет смысла вкладывать деньги в полноценный объект-ориентированная модель домена .

Чем сложнее бизнес-логика (и чем больше домен), тем быстрее процедурный код превращается в код спагетти: процедуры начинают вызывать друг друга с разными пред-постусловия (в несовместимом порядке), и они начинают требовать постоянно растущих объектов состояния.

Статья Мартина Фаулера о моделях анемичных доменов , вероятно, является лучшей отправной точкой для понимания, почему (и прив каких условиях люди возражают против размещения бизнес-логики на уровне сервиса.

Answer 2

Сервисный уровень сам по себе не является анти-паттерном, это очень разумное место для размещения определенных элементов вашей бизнес-логики. Тем не менее, вам необходимо применить осторожность к дизайну сервисного уровня, гарантируя, что вы не крадете бизнес-логику из своей доменной модели и объектов, которые ее составляют.

Тем самым вы можете получить истинную анти-модель, модель анемичного домена. Это подробно обсуждается Мартином Фаулером здесь .

Ваш пример IAuthenticationService, возможно, не лучший для обсуждения проблемы - большая часть логики вокруг аутентификации может рассматриваться как живущая в службе и не связанная с объектами домена. Лучшим примером может быть, если у вас был какой-то IUserValidationService для проверки пользователя или, что еще хуже, служба, выполняющая что-то вроде заказов процессов - служба проверки удаляет логику из объекта пользователя, а служба обработки заказов забирает логику из объекты вашего заказа, а также, возможно, объекты, представляющие клиентов, уведомления о доставке и т. д. *

Answer 3

У вас должно быть 4 слоя с DDD: презентация, приложение, домен и инфраструктура. Все, что зависит от логики прецедентов (сущности приложения, компоненты рабочего процесса приложения, например DTO, службы приложений), переходит на прикладной уровень (логика приложения). Вся инвариантная к логике прецедентов (бизнес-сущности, компоненты бизнес-процессов, например, модель домена, доменные службы) переходит на уровень домена (логика домена). На уровне инфраструктуры могут быть IoC, Cache, Repositories.