Интерфейс для вариантов использования (сервисы приложений)?

Question

Должны ли варианты использования или службы приложений иметь интерфейсы и реализации при использовании гексагональной архитектуры с принципами ddd? Например, вариант использования «удалить видео», должен ли он иметь IDeteVideo (интерфейс) и DeletVideoImpl (реализация), реализующие этот интерфейс?

Если ответ «да», где должны быть интерфейсы вариантов использования, на уровне домена или на уровне приложения? Очевидно, что реализация всегда должна быть на уровне приложения.

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

Заранее спасибо.

Answer 1

Я не вижу необходимости в интерфейсах для ваших прикладных служб. Поскольку они обычно организуют определенные c сценарии использования приложений, не должно быть разных реализаций одного и того же типа рабочего процесса. Кроме того, они не должны иметь зависимости от самой инфраструктуры, а скорее организовывать рабочий процесс действий, которые должны произойти, путем вызова операций в репозиториях, доменных службах или агрегатах.

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

Однако, если есть интерфейсы для ваших приложений (или вариантов использования), интерфейсы должен быть определен на уровне приложения. Это то же правило, что и для интерфейсов домена (например, интерфейсов репозитория), которые должны находиться на уровне домена.

Answer 2

Должны ли варианты использования или службы приложений иметь интерфейсы и реализации при использовании гексагональной архитектуры с принципами ddd?

Короче говоря, вам обычно не нужны интерфейсы на варианты использования (также называемые интеракторами в чистой архитектуре), потому что ваши основные адаптеры (клиент вашего шестиугольника) по своей природе зависят от шестиугольника.

Имейте в виду, что он вам все равно понадобится при создании вторичный адаптер (внешний компонент, используемый вашим вариантом использования), потому что ваш шестиугольник НЕ ДОЛЖЕН зависеть от каких-либо вторичных адаптеров.

НО, вам все равно может понадобиться интерфейс для ваших вариантов использования, если:

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

• Возможно, вы захотите попробовать несколько альтернатив для вариантов использования, чтобы поэкспериментировать, в этом случае он будет действовать как значимая абстракция. ции.

Если да, то где должны быть интерфейсы вариантов использования? На уровне домена или на уровне приложения?

Он должен быть размещен внутри шестиугольника на уровне уровня приложения, потому что каждый из этих интерфейсов определяет службу приложения.

Answer 3

Я думал о том же. Поскольку у вас есть только один вариант использования для службы приложения , вам не нужен интерфейс. Это происходит из моей практики с разными командами, в которых у нас не было интерфейса только для одной реализации. Кроме того, я согласен с тем, что интерфейсы службы приложений (если они у вас есть) должны быть определены на уровне приложения. Но я видел их также на уровне инфраструктуры.

Answer 4

При реализации DDD с использованием шестигранной арки интерфейсы сервисов приложения являются портами драйверов (граница варианта использования, левые края шестиугольника).

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