I always hated doing things just because "it's standard", "that's how you need to do things", "best practice", etc. People who do this kind of stuff never understood the point. They have no idea what they're doing. I never understood why people just create an interface for everything, and when they need to change the implementation, they create another interface with a different class that implements it. What was the point of the interface in the first place if you just create a new one?
What if I use an interface to reduce dependencies between layers? For example, I always create an IUserRepository interface in the domain layer and then implement it with a UserRepository. In that case, Iām reducing the dependency of the infrastructure on the domain, which aligns with Clean Architecture, right?
Depending on the language and toolchain, you could argue that introducing an interface creates a seam that makes testing easier. That was especially true when spinning up storage instances was slow and expensive.
Today, however - with tooling like devcontainers - itās often simpler and more effective to test the full stack rather than isolating components behind artificial boundaries.
Thanks for sharing your thoughts and experiences Neural Foundry!
Yeah, at some point, I found the same: no new implementations come! š
Answering your question, in my experience, I don't see a great difference. It's true that people with a lot of expertise and a very keen interest in software architecture handle better when it makes sense or not to add interfaces.
Let me know your thoughts if you give it a try at the delegation pattern š
I always hated doing things just because "it's standard", "that's how you need to do things", "best practice", etc. People who do this kind of stuff never understood the point. They have no idea what they're doing. I never understood why people just create an interface for everything, and when they need to change the implementation, they create another interface with a different class that implements it. What was the point of the interface in the first place if you just create a new one?
Thanks for sharing Paul!
Indeed, we have to understand why do things so we can take the right decision.
What if I use an interface to reduce dependencies between layers? For example, I always create an IUserRepository interface in the domain layer and then implement it with a UserRepository. In that case, Iām reducing the dependency of the infrastructure on the domain, which aligns with Clean Architecture, right?
Hey reader,
Thanks for your question.
Quick answer: you are not reducing dependencies, but decoupling... Or at least by the book.
Now, let's think.
I can imagine that the UserRepository implements the communication with MySQL or Postgresql, right ?
Do you have any other class that implements the IUserRepository?
If the answer is no, then ask yourself: what's the difference of using the Interface or the unique class directly?
Depending on the language and toolchain, you could argue that introducing an interface creates a seam that makes testing easier. That was especially true when spinning up storage instances was slow and expensive.
Today, however - with tooling like devcontainers - itās often simpler and more effective to test the full stack rather than isolating components behind artificial boundaries.
Thanks for sharing Yannick!
I'm a big fan of testcontainers šŖš½
Thanks for sharing your thoughts and experiences Neural Foundry!
Yeah, at some point, I found the same: no new implementations come! š
Answering your question, in my experience, I don't see a great difference. It's true that people with a lot of expertise and a very keen interest in software architecture handle better when it makes sense or not to add interfaces.
Let me know your thoughts if you give it a try at the delegation pattern š