DDD и отметка данных в качестве входных данных - PullRequest
0 голосов
/ 08 марта 2012

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

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

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

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

Любые указатели / комментарии / пламя благодарны.

Ответы [ 2 ]

0 голосов
/ 19 марта 2013

Я считаю, что концепции из DDD прекрасно работают с Rx.В то время как Asti делает хороший выбор в пользу неизменности, в конечном итоге большинству приложений где-то нужна мутация.Я считаю, что если вы можете определить, где происходят ваши мутации, то это хороший средний уровень.

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

Имея это в виду, теперь мы можем иметь Арку, где Репозиторий возвращает вам ваш Совокупный корень ,Ваш Aggregate Root может вызывать Службы , которые предоставляют последовательности данных, в идеале Типы значений .Ваш Aggregate Root теперь может применять какую-либо доменную логику к входящим данным (что может включать изменение собственного состояния).

Так что я бы предположил, что ваш рабочий процесс будет выглядеть примерно так:

  • Потребитель запрашивает AggRoot из репозитория
  • Репозиторий использует фабрики для создания или создания экземпляра AggRoot
  • AggRoot внедряется со службой при создании
  • Затем потребитель вызывает некоторые функции AggRoot
  • Это вызывает базовый сервис для получения последовательности.
  • AggRoot подписывается на последовательность и обрабатывает эти данные.
0 голосов
/ 09 марта 2012

Rx - это способ абстрагирования состояния и частоты с помощью комбинаторов, чьи состояния изолированы друг от друга. Единственные места, где у вас есть изменчивость в Rx, это когда вы используете Предметы. Так что, как правило, изменение объекта и отправка уведомлений о его мутировании не очень функционально (как насчет повторного входа?)

Если у вас есть несколько различных услуг, система Pub / Sub хороша. Публикация может происходить из нескольких точек и может быть объединена в поток, и в конкретном потоке может быть много подписчиков.

...