Вообще говоря, и в принципе, они служат разным целям.
Вы используете службу, когда вам нужно «что-то сделать», например, взаимодействовать с REST API, кэшировать данные или что-то еще, что может входить в обслуживаемый интерфейс, может быть повторно использовано и привязано к времени жизни приложение.
С другой стороны, событие предназначено для «реакции» на вещи. Например, когда происходит событие щелчка, необходимо запустить и обработать обратный вызов, и его время жизни не привязано к времени жизни приложения, а, скорее, к времени жизни события и его обратного вызова.
Конечно, нет причин, по которым вы не можете смешивать два (например, наличие наблюдателя EventEmitter <> / RX внутри службы вполне нормально, если ваша служба является «реактивной»; например, когда она прослушивает соединение через веб-сокет и должна уведомить 1 -N подписчиков), но общий принцип дизайна должен заключаться в использовании службы / событий там, где они имеют смысл.
Кроме того, как вы упомянули, службы являются глобальными (в контексте / модуле), тогда как события и свойства обычно локализованы. По этой причине лучше всего использовать службы, где имеет смысл глобальное взаимодействие (например, общая инфраструктура), и использовать события / свойства там, где они должны быть локализованы.
Что я предлагаю:
Используйте службы, где вам необходимо выполнить кэширование, вам необходимо выполнить внешнюю связь (websocket / webapi) или когда вам нужно разделить общие функции между несколькими компонентами / службами / слоями.
Используйте события и свойства, единственное намерение которых - поделиться данные между двумя (или более, если они связаны) компонентами, поскольку они обычно более чистые для этой цели (интерфейс компонента будет определять, что именно он вводит и что выводит).
* 1016 создайте слишком много «сервисов», которые действуют только как шлюз связи между вашими компонентами, где события / свойства (ввод и вывод) имеют больше смысла.