October CincyRb - Jim Weirich on Decoupling from Rails

What people said

theptip · 2016-11 · Recommendation

I'm interested to hear the patterns that users of MVC frameworks like Rails and Django have adopted when "fat models" start to become unwieldy. The video "Decoupling from Rails"[1] that's linked in this article was quite interesting, and argued a complete separation of business logic from the model code, to allow the business logic to be tested (and reused) more easily. I've definitely found fat-model code to be tricky to mock and test at times in Python/Django, as mocking out the ORM is gnarly. But if the business logic operates on proxy objects, then it would be much easier to do so. On the other hand, DHH's retort to this approach also makes some good points regarding the introduction of excess complexity[2]. It's a fair point that architectural decisions should not be motivated by the speed of the UTs. But perhaps there are other benefits to the Hexagonal architecture, as well. [1]: [VIDEO] [2]: [LINK]

Read the original HN comment ↗

theptip · 2017-04 · Reference

This is a powerful technique, though I'd say it's more useful for the build pipeline than for developers running UTs while coding (since the schema can change more frequently while doing so). To provide a counterpoint though, an advantage touted by advocates of complete decoupling from the DB is that your UT suite can run in O(one minute), rather than O(ten minutes). E.g. see [VIDEO] . I'm not 100% sold on this approach yet (separating your domain objects entirely from the ORM wrapper is an uphill struggle), but it's interesting.

Read the original HN comment ↗

theptip · 2017-03 · Reference

Here's a retort to that argument from the source (Uncle Bob): [LINK] DHH wrote an article with the title "test induced design damage", not sure if he coined the term. I think there's a grain of truth there; it is possible, but not necessary, to mangle your architecture to enable testability. The case that DHH was complaining about is quite interesting in itself; it was an architecture that Weirich suggested ( [VIDEO] ) where the framework DB models (in his case Rails) are separated from the Domain Models, to allow you to 1) run your tests of the business logic faster (without spinning up a DB) and 2) decouple your business logic from your choice of framework. I've felt the need for this factoring in my own code, but actually making it happen is tricky, since you lose a lot of the magic that makes your life easier (but that also couples every level of your architecture to the framework's concepts).

Read the original HN comment ↗