This describes the intended architecture for service container/factory of services providing the access to entity data in Wikibase.

The instantiation logic of those services will be moved out of WikibaseRepo/WikibaseClient top-level factories. Instantiation of those services will be also independent of both Repo and Client components.

The interface of the service container/factory of data access services WikibaseServices will be created. Repo and Client components will use the new container to get services they need.

Service instantiation logic will be moved to wiring files that container/factory implementation will use.

Services provided by WikibaseServices would include, among other services, services that aware of "dispatching" interface providing the repository-agnostic way to access data of entities stored in multiple repositories. Note that not all services would use this, so WikibaseServices will probably include the existing DistachingServiceContainer/Factory, not just be expanded version of it.
It might be possible to move the instantiation logic of per-repository services used in the dispatching scenario to the wiring files of the dispatching service container, and thus reduce the number of wiring file layers.

Extensions will be able to register their own services using their own wiring files. Extensions could also create their own interface providing easier/simpler access to extension services.

The intended architecture is also outlined on the picture below:

Initially existing interface and classes (EntityDataRetrievalServicesFactory, DispatchingServiceFactory, RepositoryServiceContainer, etc) and related wiring files will be moved to a separate component. That will be followed by creating the actual WikibaseServices interface and its implemenentation(s) and moving all relevant services step by step from Lib, and/or Repo/Client components to the Data Access component.