October CincyRb - Jim Weirich on Decoupling from Rails

…ts, 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 complexity2. 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: link to this video 2: link…

Am I only the only one that doesn't find 'All tests in 4 minutes, all model tests in 80 seconds' very impressive? It sounds like a really long time to me. You know what could increase the speed dramatically.... decoupling. I also think decoupling phrased in the context of the Rails 2 to Rails 3 upgrade, where pretty much everything changed, makes perfect sense. Imagine just having a few wrapper classes that spoke to Rails and only having to adapt them. Sounds good to me! Bernhardt: Boundaries link Weirich: Decoupling from Rails link to this video Wynne: Hexagonal Rails link

Decoupling business logic from web frameworks might be an interesting architectural problem that could use better tooling. Here's Jim Weirich going about it manually in Rails: link to this video

…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 ( link to this 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,…

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 link to this 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.

You can create a presenter, an interactor or something else. Here's a video about some concepts you can use. This video describes some decoupling for RoR but it can be applied to .net mvc. October CincyRb - Jim Weirich on Decoupling from Rails

Architecture - The Lost Years Also check the following video, it's for ruby on rails but a lot of what happening there can be carried into asp .net mvc Jim Weirich on Decoupling from Rails