В моем проекте у меня есть рабочий процесс, который работает с несколькими объектами для выполнения бизнес-транзакции. Какое лучшее место для представления логики рабочего процесса? в настоящее время я просто создаю «XXXManager», который отвечает за сотрудничество с объектами сущностей для заключения бизнес-транзакции. Есть ли другие варианты?Управление доменом: где лежит логика рабочего процесса?
DDD может быть не совсем такой, поэтому я хотел бы взглянуть на архитектурный шаблон Service Layer. Книга Мартина Фаулера «Модели архитектуры предприятия» - хорошая книга, которая объяснит это. Вы можете найти описание шаблона на веб-сайте Фаулера.
Создание систем документооборота может быть сложной перспективой. Считаете ли вы использование Workflow engines?
Если вы правильно поняли, вам нужно будет создать менеджера, который отслеживает различные транзакции в рабочем потоке, связанные с пользователем. Возможно, есть другие способы сделать это, но я всегда использовал двигатели.
Обычно существует объект домена, который должен фактически обрабатывать элемент управления, который ошибочно принимается за «сущность».
Есть ли экземпляр объекта, созданного в результате этого рабочего процесса? Если это так, логика рабочего процесса, вероятно, принадлежит там. Рассмотрим «Порядок» в приведенной ниже модели.
alt text http://img685.imageshack.us/img685/4383/order.png
Одер как существительное и глагол. «Заказ» - это объект, созданный в результате «Заказ». Как и любой хороший класс, он имеет как данные, так и поведение (и я не имею в виду геттеры и сеттеры). Поведение - это динамический процесс, который идет с данными, т. Е. Процесс упорядочения заказов. «Заказ» - контроллер.
Именно поэтому OO была изобретена.
Я бы сказал, что вы поступаете правильно, имея что-то, сотрудничающее с несколькими объектами, чтобы что-то сделать. Важно то, что каждый объект (и каждый сервис) должен иметь single responsibility.
Общесистемный рабочий процесс, о котором вы говорите, является тем, что вы можете рассматривать как часть вашего уровня приложения.
According to Paul Gielens (перефразируемый). Ответ на прикладной уровень заключается в том, чтобы переварить запрошенные в масштабе запросы (сообщения/команды) для достижения определенной общей цели. Он делает это, отправив сообщение в доменные службы для выполнения. Затем он также (необязательно) решает отправить уведомления в службу инфраструктуры.
Но тогда что такое «Сервис» ?! Это перегруженная термин, но один, который хорошо описан (опять же, by Paul Gielens)
Вы также можете прочитать о Onion Architecture для новых идей ...
txn для ссылки на Луну, интересная статья! –
Для больших ответов, я хотел бы добавить "domain events" (ссылка это всего лишь одна возможная реализация), что и сам Эванс стал уделять больше внимания ("increased emphasis on events").
Можно сказать, что OO-доменное моделирование - это обнуление глаголов. –