Кто отвечает за процесс с запросами API в доменном уровне DDD (Domain Driven Design)

Question

Кто отвечает за процесс с запросами API в доменном уровне DDD (Domain Driven Design)

Для этого вам необходимо использовать webhook или тему IOT или расписание лямбда. Поскольку вы публикуете сообщения на тему SNS, тема должна быть подписана на так называемую функцию Lambda. После этого со стороны приложения вы должны запускать функцию лямбда всякий раз, когда появляется сообщение из темы SNS. Поэтому со стороны приложения мы должны иметь лямбда, которая запланирована на определенное время (5 минут), иначе мы не будем запускаться, когда данные сообщения SNS, которые были переданы в лямбда-функцию.

Вместо использования расписания lambda мы можем использовать тему webhook или IOT, где мы подписываемся на нее, а лямбда, которая была подписана на тему SNS, будет публиковать ее данные / сообщения в теме webhook или IOT. Поэтому вскоре после публикации данных по IOT или webhook со стороны приложения у нас всегда есть подписка на нее, и мы получим данные в реальном времени.

1

domain-driven-design

задан komei7174 20 January 2019 в 11:51

2 ответа

Другие вопросы по тегам:

domain-driven-design

Похожие вопросы:

score 0 · Answer 1

Я новичок в DDD. Я понятия не имею, кто отвечает за процесс с запросом API.

Бизнес-логика принадлежит модели предметной области, а оркестровка - приложению.

Таким образом, логика в вашем приложении обычно будет выглядеть примерно так ...
Order order = orderRepository.get(orderId);
order.cancel();
Модель Порядка отвечает за знание того, как манипулировать собственной структурой данных в памяти, когда вызывается Order::cancel. OrderRepository отвечает за постоянство. Приложение запускает вызов двух других элементов.

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

Обновление 20190120
Но кто обновляет базу данных на сервере? Ваш код кажется, что база данных на сервере еще не была обновлена, если order.cancel () обновляет только собственную память. Это мое мышление.

Это действительно важный вопрос, не так ли? :)

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

В псевдокоде:
beginTransaction();
Order order = orderRepository.get(orderId);
order.cancel();
commitTransaction();
Суть в том, что лежащий в основе маппер может просмотреть хранилище и определить, какие объекты «грязные», и, таким образом, сгенерировать соответствующие вызовы для вашего постоянный магазин.

Совсем недавно, вы, скорее всего, увидите репозитории с хранилищем , а не с семантикой сбора
beginTransaction();
Order order = orderRepository.get(orderId);
order.cancel();
orderRepository.save(order);
commitTransaction();
Базовая механика та же, но мы устранили некоторые из магия того, как изменения делятся.

score 0 · Answer 2

Есть альтернативы этим вариантам. Один из них - покончить с хранилищем, и пусть модель определит поведение:

public interface Order {
    void cancel();
}

, а затем реализует поведение с помощью определенной технологии:

public final class SqlOrder implements Order {
    ...
    @Override
    public void cancel() {
        connection.execute("update order...");
    }
}

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