Last talk I followed today was titled “I heart complexity” by Adam Keys (http://therealadam.com/). It turned out to be quite an interesting talk.
Rails was designed to be as simple as possible, but sometimes you just have a complex application domain. Adam looked into making complex problems more tractable by splitting them up.
1. Domain modelling
Domain Driven Design. Bring programming language up to level of domain (DSL?), and vice versa to the point where they meet. This will result in an ubiquitous language, which reduces the amount of documentation you will have to write. This is expressed in your code as Entities (e.g. ActiveRecord models), Values (these are the glue /metadata, non unique things e.g. money), Services (they tie things together to get things done, e.g. routingservice). Then focus on the essence: essence = domain + intention. This will result in less ceremony of your technology.
2. Stateful logic
Instead of flags, use a statemachine (e.g. use the AASM plugin)
Don’t use floats, use a Money object with currency and cents (integer). Tthere is a Money gem for this that can even convert between currencies.
4. Time Travel
You could use something like acts_as_versioned.
5. Asynchronous Processing
You could use a message queue for this.
Adam shows an example of keeping track of moderations to a product catalog that need to be approved. Instead of a messagequeue he uses a statemachine to model a queue. Nice example.
AASM plugin (state machine)