Servicios enlazados en el patrón MVVM

Estoy trabajando en una aplicación de Android (en Java) y tratando de utilizar la arquitectura de aplicación recomendada por Google, pero no puedo encontrar la forma en que los servicios encajan en esta arquitectura. He buscado mucho en línea y parece que no hay un consenso claro sobre cómo debería hacerse.

Para contextualizar, mi aplicación comunica con un dispositivo BLE. He creado BLEService que extiende Service para establecer la conexión con el dispositivo y proporcionar métodos para enviar datos al dispositivo. El dispositivo también puede enviar datos de vuelta (y por lo tanto necesita notificar a la aplicación cuando se reciben datos).

Mi pregunta es, ¿dónde debería residir la ServiceConnection y cómo debería ser detenida/iniciada? Según mi investigación, hay algunas opciones que tienen sus pros y contras.

1. El servicio se inicia/detiene en la actividad, la actividad observa los eventos del servicio y los envía al modelo de vista para su procesamiento. Este patrón mantiene todos los componentes de Android juntos, pero da más responsabilidad a la vista de lo que creo que debería tener. La vista debería ser responsable sólo de manejar la UI.

2. El servicio se detiene/inicia en el modelo de vista (quizás mediante la extensión de AndroidViewModel). El modelo de vista observa los eventos del servicio y procesa los eventos. Este patrón es agradable porque el modelo de vista maneja la lógica de negocio, sin embargo, si el servicio implementa sus eventos a través de LiveData, Google dice que el modelo de vista no debe observar LiveData. Otra opción es que el servicio implemente eventos a través de algo como EventBus, pero hay muchas personas en contra de usar EventBus porque es fácil de abusar. También he oído que el modelo de vista no debe tener código específico de Android para fines de prueba.

3. El servicio existe en algún tipo de repositorio/modelo. El modelo de vista envía y observa eventos del repositorio/modelo. Esta solución es útil porque el uso de un dispositivo Bluetooth parece encajar con el propósito previsto de lo que es un modelo. Sin embargo, sufre el mismo problema de que el modelo de vista no debe observar LiveData. He visto sugerido en este caso el uso de Transformations.switchMap, que hace que un LiveData en el modelo de vista se actualice en respuesta a un cambio en un LiveData del repositorio. No estoy totalmente claro en el uso de esta estrategia, o cómo funcionaría en mi caso específico. También está la cuestión de que el repositorio necesita acceso a Context, y he oído que es mala práctica mantener una instancia de Context. Además, también he leído que un repositorio no debe mantener callbacks de la modelo de vista.

Estoy seguro de que no hay una solución perfecta, pero si alguien pudiera señalarme la dirección de las mejores prácticas, particularmente en mi caso de uso, sería de gran ayuda.