Clojurians Log v2

Nothing really; I've just run into a few edge cases where boundaries complicated things, so my advice is: use boundaries if it makes sense to do so, having a clean border between your logic and outside resources makes the code easier to test and reason about. However, sometimes there's no obvious way to implement a boundary that isn't just a copy of the API it's bordering.

That wiki is for the old Duct, so take what it says with a grain of salt. I updated the README to add a deprecation message, but forgot that the wiki existed. I'm less bullish on boundaries these days, having had time to find more edge cases where boundaries are not suitable. That said, I still think they're a good tool for enforcing your application borders, and they work well with stubbing tools like Shrubbery. In general you should use the highest level interface you can get away with, because that results in the loosest connection. For example, some databases might have functionality to allow an atomic credit/debit operation, but lack true transactions. Or perhaps there are limitations on the transaction that apply to one database but not the other. So this would favor using a higher-level transfer method. However, it's often the case that in practice things are messier, and if you find that avoiding a lower-level with-tx method is causing you more pain than it solves, then err on the side of practicality. Use the highest level interface you can get away with, but sometimes you can't get away with it.

what are you now more bullish on instead of boundaries?