Задать вопрос

Доменные сервисы, SRP и божественные объекты?

Есть некий доменный сервис ProjectService, который содержит в себе огромное количество бизнес-логики, связанной с доменной сущностью Project. Проблема в том, что этот объект сейчас по факту является божественным объектом, сильно нарушая и принцип единичной ответственности (SRP), и принцип разделения интерфейса (IRP), что очень усложняет тестирование. Кроме того, из-за большого количества методов и приличного объема кода становится сложно разбираться в том, что же там внутри происходит.


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


Как бы вы это сделали? Ещё было бы интересно узнать, как это правильно делать в контексте CQRS?
  • Вопрос задан
  • 2904 просмотра
Подписаться 4 Оценить Комментировать
Помогут разобраться в теме Все курсы
  • Stepik
    PRO C#. ASP.NET Core. Потоковый с бонусами
    2 месяца
    Далее
  • Яндекс Практикум
    Продвинутая разработка на C# и .NET
    5 месяцев
    Далее
  • Учебный центр IBS
    DEV-005 Управление зависимостями в .NET
    1 неделя
    Далее
Пригласить эксперта
Ваш ответ на вопрос

Войдите, чтобы написать ответ

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