3 ms·
> The solution is to ensure that these dependencies handle > separate concerns and have simple interfaces which allow > them to be loosely coupled with the
by lhnz 5y ago
> The solution is to ensure that these dependencies handle
> separate concerns and have simple interfaces which allow
> them to be loosely coupled with the main project logic
> in such a way that they can be updated independently of
> each other.
If your requirements ever change, you will need to make changes to these simple interfaces. At this point you will have to make changes to multiple repositories. Some changes can be done without breaking changes, but sometimes a change must be a breaking change.
A 'single' monorepo makes your problem easily solvable using automation and code. You can use a multirepo if you prefer to solve problems using human coordination.
- cryptica 5y agoI've worked on several projects/codebases which could handle requirement changes whilst rarely requiting changing the interfaces of dependencies. It's not easy to design a system this way, but it's possible and it's a worthy goal to aim for. Making it out as if it's simply not possible is not only mediocre, it's untrue.
- lhnz 5y agoIt would be mediocre if I suggested that all changes are breaking changes and didn't know about additive changes, deprecations, or (kelvin) versioning. If an API turns out to be insecure and has to be removed or a mitigation put in place that changes it's behaviour that can be an unavoidable breaking change. Either way, my point wasn't that "breaking changes always have to be made" but "avoiding making breaking changes because everything has to be deployed granularly slows you down and so does needing to make the same change in N places".