undefined | Better HN

0 pointsberkes4y ago0 comments

And 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.

0 comments

3 comments · 1 top-level

dundarious4y ago· 2 in thread

Sometimes 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.

berkesOP4y ago

I'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.

dundarious4y ago

Yes, wrap a useful "flow" for your application, rather than functions. Often I find there is just one flow for a dependency.

j / k navigate · click thread line to collapse