Foundations for component and service models and Principles of Loosely Coupled API's indirectly discuss some of the main principles behind CarrierWave.
I see CarrierWave as a middle ground between EJB and web-services, tight coupling and loose coupling, respectively.
It forces the client to a CarrierWave contained back-end to think in terms of documents, and to make conscious decisions if it should couple to the business semantics of the business objects, or only manipulate them via their meta-data.
In term of the above pages,
- the client interface presents few verbs (select, modify, delete, and invoke)
- object graph closures are named and versioned
- interactions are in terms of a particular graph (documents)
When you need more abstraction, less coupling, you can interpose a veneer as the interface to a CarrierWave container. For example, to provide web-services fulfilled by existing business logic.
One caveat, CarrierWave only provides versioning of the Idiom describing Document retrieved, and not a sequence of calls that formulate or build a Document. But if the plan is satisfied maybe that is sufficient.
Leave a comment