3 ms·

> Sometimes it's best to be DRY right from the start. In your case I don't see how it couldn't be refactored later on once you have the domain knowledge. In ou

> Sometimes it's best to be DRY right from the start. In your case I don't see how it couldn't be refactored later on once you have the domain knowledge. In our company we always have 2 types of projects planned. We can't always ship new features under type 1. And refactoring is something we must do under the 2nd type to reduce the tech debt. With 2 type of projects in mind we always plan the capacities for both types of projects And that's how exactly how you should do dry. Once you see the repeated pattern, you should refactor it. I'm in the finance factor and we are seeing this kind of 'similar but not the same' problem a lot. We are constantly in the process onboarding new payment use cases while doing refactors to abstract away the common patterns.

barfbagginus 2y ago
In some cases I would prefer to have two separate clear yet repetitive use cases, than to have, for example, a single abstract use case, that gets injected with two different factories at configuration time, depending on which sub case you want. In that case, reading and maintaining two simple use cases might be less work than reading an abstract use case, backtracking to the available factories, and then mentally interpreting the injection and factory behavior. Unless your abstractions really really make things just way simpler, being explicit could be better. Another place where this repetition tends to help readability more than it hurts maintainability is in test cases. Often abstracting things out with a little test fixture is helpful. But then being obsessive about this ends up making tests harder to maintain since there's all this long distance coupling that you constantly have to maintain. It seems that outside of test cases and use cases, we want to be much more diligent about DRY and picking the right abstractions - that makes logic in our use cases much simpler and more coherent. While inside the use case or test case, a little duplication of business logic is not so bad, and can actually improve the narrative of the code.

barfbagginus 2y ago

In some cases I would prefer to have two separate clear yet repetitive use cases, than to have, for example, a single abstract use case, that gets injected with two different factories at configuration time, depending on which sub case you want. In that case, reading and maintaining two simple use cases might be less work than reading an abstract use case, backtracking to the available factories, and then mentally interpreting the injection and factory behavior. Unless your abstractions really really make things just way simpler, being explicit could be better. Another place where this repetition tends to help readability more than it hurts maintainability is in test cases. Often abstracting things out with a little test fixture is helpful. But then being obsessive about this ends up making tests harder to maintain since there's all this long distance coupling that you constantly have to maintain. It seems that outside of test cases and use cases, we want to be much more diligent about DRY and picking the right abstractions - that makes logic in our use cases much simpler and more coherent. While inside the use case or test case, a little duplication of business logic is not so bad, and can actually improve the narrative of the code.