Доменное управление: менеджер и сервис - PullRequest
7 голосов
/ 13 марта 2010

Я создаю некоторую бизнес-логику в приложении, но я не уверен, как или где ее инкапсулировать, я использовал шаблон репозитория для доступа к данным, я видел несколько проектов, использующих DDD, которые имеют некоторые классы с суффиксом «Service» и суффиксом «manager», что каждый из этих пунктов предполагает в DDD?

Ответы [ 3 ]

24 голосов
/ 13 марта 2010

Постарайтесь быть максимально конкретным с именем. Как правило, я бы избегал названия "менеджер" , поскольку его значение довольно расплывчато.

Типичными действующими лицами / существительными бизнес-логики могут быть Валидаторы, Правила, Поставщики, Супервизоры, Импортеры / Экспортеры, Сериализаторы, Процессоры (обрабатывают транзакцию) и Репозитории (последний из которых у вас уже есть). Если один класс выполняет более одной из этих функций, он, вероятно, должен быть разбит на подклассы.

Вы задали вопрос, "о чем заботятся эти классы?" и действительно, в этом все дело. Имя SomethingManager вам ничего не говорит. OrderValidator, с другой стороны, довольно ясно говорит вам, что делает класс, как и CustomerHistoryExporter. Услуги вроде как в серой зоне; если сервисы названы в честь пассивного действия, например ShippingService, то довольно ясно, с чем работает сервис, но лучшее имя может быть чем-то вроде ShipmentDispatcher. Вы поняли идею, я надеюсь.

9 голосов
/ 13 марта 2010

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

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

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

1 голос
/ 13 марта 2010

В сценарии, в котором вы решили использовать шаблон модели домена (ясно, если вы хотите использовать DDD), бизнес-логика, такая как проверки, вычисления и бизнес-правила, определенно является частью модели домена (ваши бизнес-объекты и их отношения). ).

Хороший общий справочник может также дать вам книгу Мартина Фаулера 'Шаблоны архитектуры корпоративных приложений' .

...