Im not well versed in game programming, however I have some knowledge on how to properly structure your software architecture in other domains.

In regards to third party dependencies I agree with what Uncle Bob says, which is to keep them as far away from your stuff as possible. Only introduce a hard dependency if you have to. In my current project I have been doing that and I enjoy the flexibility that this gives me.

For example I can exchange the DI framework for the whole project in a matter of days if need be.

Which leads me to my question with the Unity debacle.

Is it not possible in game development to also structure your architecture that way ? Is the extra work not justified if you have deadlines ? Or is there just a lack of common interfaces that can serve as proper abstraction ?

I am really interested if someone with more insight on game development could shed some light on that.

Thanks.

Game engines aside, this is a very late 90s/early 00s philosophy that has really not stood the test of time. The code that strictly follows this principle ends up looking like Enterprise FizzBuzz[0]. Trying to do this results usually in a lot of time spent building an abstraction layer around one thing, and that one thing not actually being replaceable because it was only ever built or tested with that one thing, so trying to replace Thing One with Thing Two is even more work as you now have to rip out both Thing One and adjust or remove the abstraction layer around it.

Abstractions aren't free, and the more complex the library you're trying to abstract, the more expensive they are.

There's nuances to this of course -- it's a lot easier to write a custom wrapper around a logging library than a DI framework, for example. But in general if you're using a third party library, things end up cleaner if you just commit to it rather than write an abstraction layer.

[0] https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpris...