litany against fear

Refactoring Complex Domains in Ruby on Rails Notes

Part of my series of notes from the Professional Ruby Conference. See them all here.

This talk is from Shane Harvie.

Inheritance vs. Delegation. Need to make sure that you’re using the right technique. Going over a simple example with a bike that has various properties. We want to be able to change the type of bike it is at runtime. State pattern would work well, but let’s use them with module extension.

However, Ruby doesn’t natively provide a way to unmix a module. However, there’s a new gem called mixology that allows you to do just that.

Domain evolution. Fat controller are bad. Service layers are good, but can get fat too. Behavior should be defined within models.

So we’re modelling a network with various nodes, in building. They can be physically connected or wirelessly at a certain frequency. Nodes can’t have more than one physical connection. Obviously a decently complex example. Getting a little lost with this example, sorry folks. Creating a service layer helped out a lot. Extracted functionality out to a separate module that handled the complex logic of building nodes.

However, changing requirements completely mucked up that model. Rewiring multiple AR models is tough! The main problem is that the logic that decides how to do the change gets mixed up with the logic that actually makes the change. The query is mixed with the modifier! There needs to be a way to figure out what the new network would look like if two nodes were connected. This goes on and on until what’s being returned gets ridiculously complicated. It’s much better to refactor out into a results object. Way more examples…I need to pick up Shane’s book.