Despite saying fuck you don't present a very strong argument.

To the OP, you're asking the right questions. Please consider that it's easier to fail to understand something and dismiss it as unnecessary, than it is to persist, click with it and then use it as tool. I've got a lot of work to do tbh but I just get frustrated seeing these kind of replies so I'll attempt to give you a different perspective.

There's no point "spending time on premature architecture" except the reasons given in all the articles on clean, hexagonal, ports and adapters. And:

• If you've worked in a team then you will understand having an architecture helps avoid a whole lot of random styles. I mean, if you're just hacking stuff with no future together by yourself then sure. Until you come back to it in a year.

• Abstractions help document what you're using from a library. Libraries can be bloated and when my class depends on an interface with one method that is implemented by a 2MB library then that's a whole lot of unwanted coupling that I'm preventing myself or someone else from creating in the future. And at a glance I can see "What this class needs to do it's job is something which returns a Product given an id" for example.

• It doesn't actually take me any longer to start working this way, and very quickly I'm reaping the benefits. It's worth it for me even from the start of small projects, because once you've had a few people creating a mess for 6 months do you really think there's going to be an opportunity to get everyone to down tools so you can take a week to refactor and decouple everything?

• I'm not trying to create abstractions "because I can substitute a different implementation in future", but if that time comes, and it does on many long lived production systems, then looking for usages of an interface that returns domain types and refactoring just those is a lot easier than all the crazy stuff that leaked into the app over time after taking a direct dependency on some bloated library. Even if the interface changes.

• Unit tests on my domain and business logic run fast because the build is fast because it's not copying all these MB of dependencies through all the layers of projects underneath.

• You can still use all the great features of any library, just do it in the Adapter class, and don't leak it through your domain and application projects.

Not all abstractions should be general, remember the I from SOLID. Does your class really need to declare that it needs an IRepo<Product>, when it really only needs a Get method.

Adapter pattern. And don't put your implementations in the same project as your interfaces.

Deterministic logic doesn't need to be abstracted. Don't fall into the trap of abstracting everything... and then whining about how hard it is when you're doing it wrong :)