Observer classes respond to life cycle callbacks to implement trigger-like
behavior outside the original class. This is a great way to reduce the
clutter that normally comes when the model class is burdened with
functionality that doesn’t pertain to the core responsibility of the
class. Example:

Observers will by default be mapped to the class with which they share a
name. So CommentObserver will be tied to observing Comment, ProductManagerObserver to
ProductManager, and so on. If you want to name your observer differently
than the class you’re interested in observing, you can use the
Observer.observe class method which takes either the concrete class
(Product) or a symbol for that class (:product):

Available callback methods

If you’re using Active Record
within Rails, observer classes are usually
stored in app/models with the naming convention of
app/models/audit_observer.rb.

Configuration

In order to activate an observer, list it in the
config.active_record.observers configuration setting in your
config/application.rb file.

config.active_record.observers=:comment_observer,:signup_observer

Observers will not be invoked unless you define these in your application
configuration.

Loading

Observers register themselves in the model class they observe, since it is
the class that notifies them of events when they occur. As a side-effect,
when an observer is loaded its corresponding model class is loaded.

Up to (and including) Rails 2.0.2 observers were
instantiated between plugins and application initializers. Now observers
are loaded after application initializers, so observed models can make use
of extensions.

If by any chance you are using observed models in the initialization you
can still load their observers by calling ModelObserver.instance
before. Observers are singletons and that call instantiates and registers
them.