Как работать с конструкторами UseCase Interactor, которые имеют слишком много параметров зависимости в DDD с чистой архитектурой?
Используя DDD с чистой архитектурой, я сначала создаю все мои зависимости (например, репозитории и службы) и внедряю их в мои UseCases. Со временем я заметил, что мой список зависимостей для каждого UseCase значительно вырос со временем. Например, мой UseCase использует 3 Aggregate Roots, поэтому у меня есть 3 хранилища. Не так плохо. Но когда я добавляю больше функций, я обнаруживаю, что добавляю доменные службы или несколько репозиториев и вынужден также внедрять их в конструктор UseCase. Можно ли иметь более 10 параметров в UseCase Interactor? Я всегда думал, что наличие более 2-3 параметров - это запах кода. Есть ли лучший способ справиться с этим? Заранее спасибо.
1 ответ
Наличие множества зависимостей в конструкторе - это определенно запах кода. Это не очень легко сделать, и часто это требует опыта и навыков, но в основном вам нужно взглянуть на свою систему с другой точки зрения и проверить, могут ли некоторые услуги / агрегаты быть заменены (объединены) новыми, которые зависят на ваших старых. Чем этот новый может в конечном итоге оказаться полезным и в других местах вашей системы, так что вы уменьшите дублирование кода. Вы должны просто следовать SRP.
Вы можете найти хороший пример здесь: http://blog.ploeh.dk/2010/02/02/RefactoringtoAggregateServices/