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

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

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


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


Как бы вы это сделали? Ещё было бы интересно узнать, как это правильно делать в контексте CQRS?
  • Вопрос задан
  • 2913 просмотров
Подписаться 4 Оценить Комментировать
Помогут разобраться в теме Все курсы
  • Stepik
    PRO C#. ASP.NET Core. Потоковый с бонусами
    2 месяца
    Далее
  • Учебный центр IBS
    Шаблоны проектирования GoF. Редакция для .NET
    1 неделя
    Далее
  • INSECA
    Malware Analysis
    14 недель
    Далее
Пригласить эксперта
Ваш ответ на вопрос

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

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