Separate your domain model from your persistence mechanism. Some problems call for a really sharp tool.
One, two! One, two! and through and through
The vorpal blade went snicker-snack!
He left it dead, and with its head
He went galumphing back.
Vorpal is a Data Mapper-style ORM (object relational mapper) framelet that persists POROs (plain old Ruby objects) to a relational DB. It has been heavily influenced by concepts from Domain Driven Design.
We say 'framelet' because it doesn't attempt to give you all the goodies that ORMs usually provide. Instead, it layers on top of an existing ORM and allows you to take advantage of the ease of the Active Record pattern where appropriate and the power of the Data Mapper pattern when you need it.
- It keeps persistence concerns separate from domain logic. In other words, your domain models don't have to extend ActiveRecord::Base (or something else) in order to get saved to a DB.
- It works with Aggregates rather than individual objects.
- It plays nicely with ActiveRecord objects!
This last point is incredibly important because applications that grow organically can get very far without needing to separate persistence and domain logic. But when they do, Vorpal will play nicely with all that legacy code.
For more details on why we created Vorpal, see The Pitch.
Add this line to your application's Gemfile:
And then execute:
Or install it yourself as:
$ gem install vorpal
Warning! API still in flux! Expect it to change with every release until 0.1.0. After this point, semantic versioning will be used.
Start with a domain model of POROs and AR::Base objects that form an aggregate:
class Tree; end class Branch include Virtus.model attribute :id, Integer attribute :length, Decimal attribute :diameter, Decimal attribute :tree, Tree end class Gardener < ActiveRecord::Base end class Tree include Virtus.model attribute :id, Integer attribute :name, String attribute :gardener, Gardener attribute :branches, Array[Branch] end
In this aggregate, the Tree is the root and the Branches are inside the aggregate boundary. The Gardener is not technically part of the aggregate but is required for the aggregate to make sense so we say that it is on the aggregate boundary. Only objects that are inside the aggregate boundary will be saved, updated, or destroyed by Vorpal.
POROs must have setters and getters for all attributes and associations that are to be persisted. They must also provide a no argument constructor.
Along with a relational model (in PostgreSQL):
CREATE TABLE trees ( id serial NOT NULL, name text, gardener_id integer ); CREATE TABLE gardeners ( id serial NOT NULL, name text ); CREATE TABLE branches ( id serial NOT NULL, length numeric, diameter numeric, tree_id integer );
Create a repository configured to persist the aggregate to the relational model:
require 'vorpal' module TreeRepository extend self engine = Vorpal.define do map Tree do attributes :name belongs_to :gardener, owned: false has_many :branches end map Gardener, to: Gardener map Branch do attributes :length, :diameter belongs_to :tree end end @mapper = engine.mapper_for(Tree) def find(tree_id) @mapper.query.where(id: tree_id).load_one end def save(tree) @mapper.persist(tree) end def destroy(tree) @mapper.destroy(tree) end def destroy_by_id(tree_id) @mapper.destroy_by_id(tree_id) end end
Here we've used the
owned flag on the
belongs_to from the Tree to the Gardener to show that the Gardener is on the aggregate boundary.
And use it:
# Saves/updates the given Tree as well as all Branches referenced by it, # but not Gardeners. TreeRepository.save(big_tree) # Loads the given Tree as well as all Branches and Gardeners # referenced by it. small_tree = TreeRepository.find(small_tree_id) # Destroys the given Tree as well as all Branches referenced by it, # but not Gardeners. TreeRepository.destroy(dead_tree) # Or TreeRepository.destroy_by_id(dead_tree_id)
It also does not do some things that you might expect from other ORMs:
- No lazy loading of associations. This might sound like a big deal, but with correctly designed aggregates it turns out not to be.
- No managing of transactions. It is the strong opinion of the authors that managing transactions is an application-level concern.
- No support for validations. Validations are not a persistence concern.
- No AR-style callbacks. Use Infrastructure, Application, or Domain services instead.
- No has-many-through associations. Use two has-many associations to a join entity instead.
idattribute is reserved for database primary keys. If you have a natural key/id on your domain model, name it something that makes sense for your domain. It is the strong opinion of the authors that using natural keys as foreign keys is a bad idea. This mixes domain and persistence concerns.
- Persisted entities must have getters and setters for all persisted attributes and associations. They do not need to be public.
- Only supports PostgreSQL.
- Aggregate updated_at.
- Support for other DBMSs (no MySQL support until ids can be generated without inserting into a table!)
- Support for other ORMs.
- Value objects.
- Remove dependency on ActiveRecord (optimistic locking? updated_at, created_at support? Data type conversions? TimeZone support?)
- More efficient updates (use fewer queries.)
- Nicer DSL for specifying attributes that have different names in the domain model than in the DB.
Q. Why do I care about separating my persistence mechanism from my domain models?
A. It generally comes back to the Single Responsibility Principle. Here are some resources for the curious:
- Architecture, the Lost Years - talk by Bob Martin.
- Hexagonal Architecture Pattern - Alistair Cockburn.
- Perpetuity - a Ruby Data Mapper-style ORM.
- EDR - another Data Mapper-style ORM framelet by Victor Savkin.
Q. How do I do more complicated queries against the DB without direct access to ActiveRecord?
def find_all @mapper.query.load_all # use the mapper to load all the aggregates end
Q. How do I do validations now that I don't have access to ActiveRecord anymore?
A. Depends on what kind of validations you want to do:
- For validating single attributes on a model: ActiveModel::Validations work very well.
- For validating whole objects or object compositions (like the state of an Aggregate): Validator objects are preferred. Chapter 5 of Implementing Domain Driven Design contains more guidance.
Q. How do I use Rails view helpers like
Q. How do I get dirty checking?
A. Check out ActiveModel::Dirty.
Q. How do I get serialization?
A. You can use ActiveModel::Serialization or ActiveModel::Serializers but they are not heartily recommended. The former is too coupled to the model and the latter is too coupled to Rails controllers. Vorpal uses SimpleSerializer for this purpose.
- Start a PostgreSQL server.
- Create a DB user called
- Create a DB user called
rakefrom the terminal.
- Fork it ( https://github.com/nulogy/vorpal/fork )
- Create your feature branch (
git checkout -b my-new-feature)
- Commit your changes (
git commit -am 'Add some feature')
- Push to the branch (
git push origin my-new-feature)
- Create a new Pull Request