DDD зачем создавать интерфейс на доменном сервисе?

Question

DDD зачем создавать интерфейс на доменном сервисе?

1

Я использую DDD для 3 моих приложений, которые используют один и тот же доменный уровень (службы домена) через 3 разных приложения (рабочий процесс). Инфраструктура и уровень пользовательского интерфейса не имеют доступа к услугам домена. Я также передаю все внешние зависимости, такие как репозиторий, через конструктор службы домена. Итак, мне нужно создать интерфейс для служб домена? Обратите внимание, что я определил интерфейс для приложений.

Parth Patel 16 июль 2014, в 08:16

Источник

0

Интерфейс может помочь вам в более детальном тестировании, но если оно вам не нужно, не создавайте его.
JefClaes 16 июль 2014, в 10:54
0

@JefClaes, ну, в этом-то и дело. Я не думаю, что (возможно, не осознавая) интерфейс службы домена мог бы помочь даже для детального тестирования, поскольку реализация службы домена была бы конкретной. Другими словами, бизнес-логика доменного сервиса не должна меняться местами. Не только это, но и единственная причина, по которой я вижу создание интерфейса в службах приложений, - это имитация его при создании модульного теста на контроллере (если мы это сделаем !!). Буду очень признателен, если кто-нибудь даст мне повод для создания интерфейса для сервиса.
Parth Patel 16 июль 2014, в 23:45
0

Я думаю, что вы рассмотрели две основные причины: если вы кодируете интерфейс и используете DI, вы можете поменять класс на другой и уменьшить зависимости, и это делает возможным / проще модульное тестирование.
Adrian Thompson Phillips 17 июль 2014, в 07:59
0

@ParthPatel Почему вы ищете причину? Вы всегда можете извлечь интерфейс, когда увидите необходимость в нем.
JefClaes 17 июль 2014, в 17:32
1

Ты прав. На самом деле, я думал об этом, потому что мой собственный класс фабрики объектов имел ограничение на автоматическое определение типов параметров конструктора объекта и не мог разрешить его из зарегистрированных зависимостей. Я заменил фабричный класс на StructureMap, и теперь все в порядке. :-) Это изменило то, как я думал о DI.
Parth Patel 20 июль 2014, в 23:48
0

@JefClaes, я могу пометить твой комментарий как ответ?
Parth Patel 20 июль 2014, в 23:49
0

@ParthPatel Я также ответил на ваш вопрос ниже.
JefClaes 21 июль 2014, в 16:58

Показать ещё 5 комментариев

Теги:

c#

interface

domain-driven-design

1 ответ

Ещё вопросы

Интерфейс может помочь вам в более детальном тестировании, но если оно вам не нужно, не создавайте его.
@JefClaes, ну, в этом-то и дело. Я не думаю, что (возможно, не осознавая) интерфейс службы домена мог бы помочь даже для детального тестирования, поскольку реализация службы домена была бы конкретной. Другими словами, бизнес-логика доменного сервиса не должна меняться местами. Не только это, но и единственная причина, по которой я вижу создание интерфейса в службах приложений, - это имитация его при создании модульного теста на контроллере (если мы это сделаем !!). Буду очень признателен, если кто-нибудь даст мне повод для создания интерфейса для сервиса.
Я думаю, что вы рассмотрели две основные причины: если вы кодируете интерфейс и используете DI, вы можете поменять класс на другой и уменьшить зависимости, и это делает возможным / проще модульное тестирование.
@ParthPatel Почему вы ищете причину? Вы всегда можете извлечь интерфейс, когда увидите необходимость в нем.
Ты прав. На самом деле, я думал об этом, потому что мой собственный класс фабрики объектов имел ограничение на автоматическое определение типов параметров конструктора объекта и не мог разрешить его из зарегистрированных зависимостей. Я заменил фабричный класс на StructureMap, и теперь все в порядке. :-) Это изменило то, как я думал о DI.
@JefClaes, я могу пометить твой комментарий как ответ?
@ParthPatel Я также ответил на ваш вопрос ниже.

JefClaes · Accepted Answer · 2014-07-21T15-08-00.000Z

Почему вы ищете причину? Вы всегда можете извлечь интерфейс, как только увидите его.