ServiceStack has been registering its IOC & Services the same way for 10+ years, it’s unlikely to change as it allows all other functionality to assume Services are configured & autowired the same way.
It’s an alternative if for some reason you didn’t want to use ServiceStack’s standard Service base class, as you’re new to ServiceStack I’d recommend sticking with the standard concrete Service.
No there’s no way to prevent ServiceStack from pre-registering its own Services, they’re pre-registered on Startup before Configure(). Leave ServiceStack Services as-is & focus on your App deps instead.
ServiceStack only binds & invokes its own Services (i.e. Service/IService), this behavior is fundamental as effectively the rest of the framework’s features builds its functionality around ServiceStack Services and the Request DTOs used to invoke them.
Beyond that you can delegate to your own dependencies which contains the actual implementation, but generally most people maintain their implementation within Services.
There are strategies you can adopt to automate this with your own conventions, e.g. gRPC, both AutoQuery RDBMS and AutoQuery Data as well as the new AutoCrud feature all generates their own Service implementations to either bind to an external endpoint like ASP.NET Core’s gRPC endpoints or for AutoQuery generates their own Services that effectively delegate to IAutoQueryDb and IAutoCrudDb which contains most of the generic implementation. However that requires advanced meta programming to use Reflection.Emit to dynamically code-gen the classes and so not a recommended strategy.