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

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


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


Как бы вы это сделали? Ещё было бы интересно узнать, как это правильно делать в контексте CQRS?