This post originated from an RSS feed registered with Ruby Buzz
by Jeremy Voorhis.
Original Post: Journaled Domain Models via the Command Pattern, or, It's All Just CRUD pt. II
Feed Title: JVoorhis
Feed URL: http://feeds.feedburner.com/jvoorhis
Feed Description: JVoorhis is a Rubyist in northeast Ohio. He rambles about Ruby on Rails, development practices, other frameworks such as Django, and on other days he is just full of snark.
I just read Jason Watkins’ followup to Jim Greer’s post about CRUD and I think Jason’s claim that simplicity is lost is dubious. State-changing methods like Ticket.close! give us a simple interface to send a command to a domain object, but they may be hiding any amount of complexity. When we introduce the TicketClosure, we let our graph of model instances tell us directly based solely on their existence. That is what enables domain operations to be reduced to simple CRUD, where each of the four primary verbs are universally understood.
Also, if we step back one level, we are reminded that a verb is also a noun on paper – we talk about performing commands on our primary domain models, but operations, actions, etc. nouns. What we are talking about is journaling state changes on entities within our domain model. If you are unfamiliar with the command pattern, I encourage you to read the Wikipedia entry about the command pattern for an excellent treatment of this design pattern.
Using Jason’s Ticket example, let’s imagine that TicketClosure inherits from TicketCommand. TicketAssignment and TicketPriorityChange could also inherit from TicketCommand, which would expose simple operations such as reassigning a ticket to another developer, etc. The ticket’s state is now a composition of the commands it has received. These commands all expose their own simple CRUD operations, and our Ticket model now supports undo operations by manipulating its journal of commands with simple CRUD.
What other uses can you envision for the command pattern as an integral part of a domain? Any criticisms?