DDD: зачем разделять методы репозитория для разных интерфейсов? - PullRequest
0 голосов
/ 13 марта 2019

Согласно IDDD_Samples Вона Вернона, интерфейс хранилища имеет несколько методов: выдача удостоверения (nextIdentity), сохранение сущности (save), получение сущности (productOfId), удалениесущность (remove) и т. д.

Однако редко используются все методы в одном сценарии использования.Например, в случае создания новой сущности используются два метода nextIdentity и save, но другие не используются.

С точки зрения I Принцип разделения сегментов интерфейса, я думал, что методы хранилища должны быть разделены на несколько интерфейсов.Как это помогает?

enter image description here

Ответы [ 2 ]

0 голосов
/ 13 марта 2019

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

Я бы описал это так: разделение интерфейса происходит за стоимость .

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

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

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

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

Лошади на курсы.

0 голосов
/ 13 марта 2019

Мой длинный ответ на другой вопрос сводился к сведению к минимуму способности клиента совершать "неправильные" поступки.

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

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

...