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.
The one-to-one relationship point really resonates. Ive defintely been guilty of creating interfaces for that just in case scenario, and youre right, that second implementtion almost never comes. The delegation pattern for testing is interesting, I hadnt considered that as an alterntive. Do you find that teams with less experienc tend to over-engineer with interfaces more often?
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 π
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 πͺπ½
The one-to-one relationship point really resonates. Ive defintely been guilty of creating interfaces for that just in case scenario, and youre right, that second implementtion almost never comes. The delegation pattern for testing is interesting, I hadnt considered that as an alterntive. Do you find that teams with less experienc tend to over-engineer with interfaces more often?
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 π