May 15, 2009
How Do Domain Modeling and Atom(Pub) Fit Together?
In various forums, I have claimed the benefits of using domain modeling (DM) to design RESTful Web resources, but explaining why is surprisingly difficult. Efforts so far have been geared towards the domain modeling crowd, but there are so many bells, whistles, and misunderstandings of DM that the simple beauty is easily missed. An appreciation of the Model-View-Controller (MVC) pattern helps immensely, but if you're like me a clear understanding of MVC is hard to come by. Last night I was thinking that an RDF route might be a more efficient. Today an AtomPub perspective seems more likely. For people who are unfamiliar with all of the above, other routes need to be mapped out. I would claim, though, that the situation is analogous to the "Ah ha!" transition from the service-oriented to resource-oriented perspective. Atom(Pub) is probably the easiest route to this realization, so the shortest path to appreciating DM probably lies in this same direction.
The first thing to note is that a collection in Atom(Pub) maps directly to a "class" in DM. There is no need to subclass in DM to accomplish this relationship. Likewise, a member in Atom maps directly to an "instance" in DM. Again, no subclassing is necessary.
The discussion becomes easier we set aside the create, update, and delete capabilities of AtomPub for the moment. We can do that because AtomPub mostly just tells us is how the URIs we need to support the Atom Syndication Format should react if we throw POST, PUT, and DELETE at them instead of GET.
Given this simplification, an Atom Feed is merely a representation of a class (collection) and an Atom Entry is merely a representation of an instance (member). It's just another representation that could/should be negotiable from a Generic Document that it shares with the text/html, text/xml, application/json, or any other representation that the server thinks is worth supporting. From the (MVC) controller POV, Atom is just another type of view (representation format) that it needs to produce from the model. Creating a class in DM that subclasses Atom would be equivalent to subclassing text/html or application/json. It's not necessary.
0 comments so far