Rough Draft Blog Post

### Is the ActiveRecord pattern the correct Pattern for Long Term preservation concerns

> Active Records are special forms of DTOs [Data Transfer Objects]. They are data structures with public variables; but they typically have navigational methods like *save* and *find*. Typically these Active Records are direct translations from database tables, or other data sources.
>
> Unfortunately we often find that developers try to treat these data structures as though they were objects by putting business rule methods in them.
> This is awkward because it creates a hybrid data structure and an object.
>
> The solution, of course, is to treat the Active Record as a data structure and to create separate objects that contain the business rules and that hide their internal data (which are probably just instance of the Active Record).
>
> -- Martin, Robert C. "Clean Code: A Handbook of Agile Software Craftsmanship (Robert C. Martin Series)" pp

ActiveRecord pattern requires/assumes keeping model and schema in-sync.
Rails mitigates this synchonization issue by introspection on the database's table.
ActiveFedora does not provide such a luxury.

Traditionally, Rails pushed ActiveRecord objects towards Fat Models.
I blame [Fat Models, Skinny Controllers](http://weblog.jamisbuck.org/2006/10/18/skinny-controller-fat-model).
But I am not without blame.
I jumped on the Fat Models train.

I remember early in Rails development having MVC related arguements about where things should go.
My coworker said "In the controller" and I said "In the model."

It turns out we were both wrong.
But we didn't have a noun to attach the behavior to.
We were talking about a Query object; Something that finds the objects that we need.
In other cases we needed a Command object; Something that transforms an object.

Consider the more general statement from Robert Martin.

> Procedural code (code using data structures) makes it easy to add new functions without changing the existing data structures.
> OO code, on the other hand, makes it easy to add new classes without changing existing functions.
>
> The complement is also true:
>
> Procedural code makes it hard to add new data structures because all the functions must change.
> OO code makes it hard to add new functions because all the classes must change.
>
> -- Martin, Robert C. "Clean Code: A Handbook of Agile Software Craftsmanship (Robert C. Martin Series)" pp 97

* What would Hydra look like without Fedora? Blacklight? Solr?
* Is direct deposit into Fedora the best way to do these things?
* Asynchronous is powerful
* We want to share code, but its free as in kittens; I don't want to be a crazy cat person @MUST

With these observations and requirements Hydramata::Works embarked on a journey