3 ms·
But at some point, isn't the hand-picked approach going to result in the same morass of version dependencies on any site of moderate complexity?
by ziggus 5y ago
But at some point, isn't the hand-picked approach going to result in the same morass of version dependencies on any site of moderate complexity?
- dundarious 5y agoIdeally you would choose dependencies with minimal dependencies of their own (very few if any common dependencies), so you have a manageable number of versions and near complete freedom of choice of those versions.
- berkes 5y agoAnd ideally, you'll wrap them too. In what is often called "Anti-Corruption-Layers". Often very simple Proxies or Adapters. Consequentially, this makes testing (in isolation) far easier too. Which also means you'll choose libraries that are decoupled by design because the others are really hard to write such wrappers for.
- dundarious 5y agoSometimes quite useful, yes, though I would strongly emphasize that the goal is not to wrap the entire API of the dependency -- that is pure busywork and doesn't stave off "corruption". Just the (consciously quite minimal) parts you actually need.
- berkes 5y agoI'll usually even add another guard: only add them if the library uses non-domain language. For example, so that you can say "chargeCard(payment)" in your domain and app, Instead of having to do things like "openAnonCustomer(payment.customerId) && pmt= addPayment(payment.amount, payment.currency) && bookPayment(pmt)" or whatever weird language, order, or transaction boundaries a library uses.
- dundarious 5y agoYes, wrap a useful "flow" for your application, rather than functions. Often I find there is just one flow for a dependency.
- gwbas1c 5y agoYes, but the whole point is that you don't have to update all your dependencies at once. Even if you do find yourself needing to update your dependencies, you can do them 1 at a time. This way you aren't stuck with a not building, completely broken codebase for days while you refactor to adapt to new changes.