Какие могут быть минусы использования SINGLETON для реализации SERVICE(служба) по принципу Domain Driven Design?

Question

[yurygolikov]

Я не очень опытный разработчик.
SERVICE не имеет состояния в DDD. И вроде бы можно использовать Singleton для его реализации. Но какие могут быть минусы при расширении проекта. Может ли в данном случае усилиться зависимость объектов или сложность тестирования.
Вообщем стоит ли использовать Singleton для службы в DDD?

Answer 1

[Виталий Витренко]

What is so bad about singletons?
Ипспользуйте DI контейнер.

Comments

[Myroslav Berlad]

а как быть в случае с Entities или Aggregates?
Вот пример с книги DDD in PHP

class Post
{
    // ...

    public function publish()

    {
        $this->setStatus(
            Status::published()
        );

        $this->publishedAt(new DateTimeImmutable());

        DomainEventPublisher::instance()->publish(

            new PostPublished(
                $this->id
            )
        );
    }
}

Изменять DomainEventPublisher::instance() на ижект DI ? Тогда как? или не использовать такой подход?

[Виталий Витренко]

Myroslav Berlad: инжектите инстанс DomainEventPublisher в поле Post(через конструктор или сеттер) и используйте его в publish().
Не уверен насчет PHP, на Java(Spring DI) это выглядело бы так

@Component
public class Post {

    private final DomainEventPublisher eventPublisher;

    @Inject
    public Post(DomainEventPublisher eventPublisher) {
        this.eventPublisher = eventPublisher;
    }

    public void publish() {
        //....
        eventPublisher.publish(postPublished);
        //....
    }

}

[Myroslav Berlad]

Виталий Витренко: думаю скорей через сеттер, родных аннотаций нету в PHP, только если DI написать/взять готовую с такой фичей. Если писать типа:

class Post 
{
        public function __construct($title, $description, $content) 
         {
                 // ....
         }
}

то будет не умесно передавать DomainEventPublisher или что то типо етого.
Спасибо за ответ :)

[yurygolikov]

Виталий Витренко: Подскажите, пожалуйста, еще вот что:
SERVICE(службы) в DDD логичнее всего устанавливать в зависимость как SINGLETON(setSingleton)? Ведь службы не имеют состояния, а значит, что создавать заново объекты нет смысла, лишняя трата ресурсов, правильно? Или все же есть какие то аргументы в пользу того, чтобы каждый раз создавать службы через DI заново?

[Виталий Витренко]

yurygolikov: да, сервисы(как и большинство immutable объектов) всегда имеют singleton scope, то есть DI контейнер создает только один инстанс на всех.

[yurygolikov]

Виталий Витренко: Спасибо еще раз :)