DDD интеграция: вопросы по обработчику команд? - PullRequest
0 голосов
/ 16 января 2020

Я использую архитектуру DDD, и мне трудно понять некоторые вещи.

Это схема моего проекта: Схема

Первая прежде чем задавать вопросы, я приведу пример, а затем задам вопросы.

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

TimeTracking (сущность root)

  • HourTrackginID
  • CompanyID
  • WorkerID
  • EntryTime
  • ExitTime

Worker (entity)

  • WorkerID
  • CompanyID
  • AllowTimeTracking
  • ListOfWorkerHolidays

Company (юридическое лицо)

  • CompanyID
  • AllowTimeTracking
  • ListOfCompanyHolidays

Праздники (Объект значения)

  • Праздники ID
  • StartDate
  • EndDate

А из нашего приложения WPF или WebService (используя и приложение или что-то еще) мы отправляем ID компании и идентификатор работника с помощью команды.

И у меня следующие вопросы:

  1. I получить команду только с workerID и companyID, но мне, очевидно, нужно получить информацию об этих объектах и ​​TimeTrackerID (если работник не имеет и ExitTime). Где это должно быть сделано? В обработчике команд через репозиторий? Или команда уже должна содержать всю информацию?

  2. Предположим, у нас есть информация о первой точке в обработчике команд, теперь мы должны создать агрегат TimeTracking root с информацией, которую мы иметь. Затем в зависимости от данных мы будем вызывать функцию DoExit () / DoEntry () объекта TimeTracking. Кто должен отвечать за добавление / обновление TimeTracking? Должны ли функции проверять бизнес-правила, такие как отсутствие выходных, разрешать отслеживание и т. Д. c и возвращать true или false, а затем обработчик команд выполняет добавление / обновление? Или функции должны создать в домене событие выполнения входа / выхода для делегирования добавления / обновления?

  3. С другой стороны, как мне обновить пользовательский интерфейс с возможными ошибками в обработчике команд? ? Например, компания не существует, об этом следует каким-то образом уведомить, так что было бы правильным решением вернуть объект в обработчик команд с указанием успеха / ошибки и типа ошибки? И то же самое при проверке правил ведения бизнеса, должен ли я также возвращать объект для сообщения об ошибке? Поэтому, если бы мы сделали следующее: при вызове DoEntry () компания не позволяет отслеживать, я возвращаю объектную ошибку в обработчик команд, который также будет возвращать эту ошибку, будет правильно?

  4. Наконец, для каждого действия, которое манипулирует и создает сущность (редактирование рабочего, удаление отслеживания времени ...), нам нужна команда?

1 Ответ

0 голосов
/ 30 января 2020

Я думаю, ваш дизайн перевернут. Я предполагаю, что WorkerID может быть связан только с одной Компанией, а HourTrackingID может быть связан только с одним Работником. Обычно ваш Агрегат Root является частью «один» отношения «один ко многим», что означает, что Worker - это AR, а TimeTracking - это агрегат.

Ваша команда будет ClockInWorker и передаст WorkerID. CompanyID не нужен, потому что эта команда не заботится о том, на кого работает работник, просто о том, что они синхронизированы. Эта команда вызовет метод Worker.DoEntry, который создаст запись TimeTracking со временем входа. Затем у вас есть другая команда ClockOutWorker, которая работает таким же образом, но вызывает Worker.DoExit.

Проверка данных (проверка, является ли workerID действительным), происходит как в API, так и в команде. Предполагая, что WorkerID является guid, API проверяет, что он получил фактический guid. API не проверяет, соответствует ли guid реальному работнику - это зависит от команды. API гарантирует, что запрос синтаксически действителен, а команда обеспечивает соблюдение бизнес-правил.

Вы не показываете, принадлежат ли праздничные дни компании или нет. Если это так, то Компания должна проверить Holiday с помощью метода Company.CanWorkerLogTime (workerID, logDate) all. Это следует вызывать из команды перед вызовом Worker.DoEntry. Вы можете получить CompanyID от Работника. Если праздничные дни не принадлежат Компании, то вы бы сделали HolidayService с помощью метода CanWorkerLogTime (logDate)

...