What if we modeled every user action as the passing of a document?

17 February 2013

I was listening to a brilliant podcast on .Net Rocks where Carl & Richard interviewed Glenn Block, Henrik Nielsen, and Darrel Miller.  The topic was Web API, but it started with Henrik talking about how he worked as a student helping to create HTTP!  Great history lesson and a great philosophical show.

It made me sit and ponder modern architecture.  When I think about the parallels of HTTP and regular business, I keep coming back to the same premise: they both run by the passing of documents. Before modern computers existed, businesses operated by filling out paper forms and then placing them in the inbox of a clerk of a department. The clerk would have access to filing cabinets, and the clerk would process the form, sometimes creating a report or a reply message in the form of another document.

When I ponder modern architecture for business applications (that are all about productivity and the access to data/information), I keep coming back to the building blocks: passing documents. I think we have gone astray as an industry a little by creating applications that "edit" a customer record. The real business process behind this used to be a "customer change of address form" that was submitted to the office - behind the scenes the clerk would use some white-out (that's too modern) and edit the actual record sitting in the file cabinet. But the interface between the person making the request and the system/clerk is the passing of a document!

Whether it is a client/server, smart phone app, or just a web application, I think we could make our designs simpler by modeling every user's operation as a document.

I would love to hear some other thoughts on this.

Read More     7 Comments


Trackbacks

What if we modeled every user action as the passing of a document? | Clear MeasureClear Measure Posted on 2.17.2013 at 6:49 PM

Pingback from What if we modeled every user action as the passing of a document? | Clear MeasureClear Measure

Web development as we know it, is dead Posted on 2.28.2013 at 8:50 AM

Web development as we know it, is dead.  We keep looking for the common runtime that can run everywhere.  We yearn (remember Java) for the platform that allows us the promise of “ write once, run everywhere ”.  This, in the global sense

Web development as we know it, is dead : Jeffrey Palermo (.com) Posted on 2.28.2013 at 1:51 PM

Pingback from Web development as we know it, is dead : Jeffrey Palermo (.com)

Comments

Zamboch said on 2.18.2013 at 7:44 AM

What about CQRS + Event source

martinfowler.com/bliki/CQRS.html

Steven Evans said on 2.18.2013 at 7:28 PM

Like Zamboch mentioned, it sounds pretty similar to the idea of Event Sourcing. But in a similar way, it reminds me of one key concept of truly functional programming: immutability. Any down-stream code can't change a piece of data that was handed to it. There's a specific action that needs to be performed for it to be changed. OOP is great in its own way, but when it comes to prevent changes to state, most languages make it too easy to do it wrong (C# is definitely one of them).

Michael L Perry said on 2.24.2013 at 1:11 PM

Documents tend to be large things. When you fill out a form, you usually have to provide a lot of redundant contextual information. You give your name, address, policy number, etc. This establishes your identity, and correlates the new document with history.

What if instead that history was itself a set of predecessor documents? Then your new request could simply reference the predecessor. Your identity, context, and history is all available by looking backward through a string of predecessors.

Then take this in the opposite direction. If you want to find out what happened with a particular request, then you could query that document for its successors. If you follow this to its logical conclusion, then the filling clerk doesn't even need access to a set of records. All you need are the history of documents, and a way to query them.

Rather than documents, I call these historical facts. A fact is a record of a decision made by an actor, usually a human.

I've documented a set of rules and patterns related to modeling a system using historical facts. You can find it at http://historicalmodeling.com.

I've also created a database and query language that lets you build mobile and web applications historically. It's called Correspondence, and you can find more about it at http://correspondencecloud.com.

Please let me know what you think. Thank you.

Chris McKenzie said on 3.15.2013 at 12:59 AM

I'm doing something that I think is similar. My MVC api controllers expose which operations are available in the application. The operations themselves are executed by a class that implements ICommand<TRequest, TResponse> where TRequest describes the required inputs of the operation, and TResponse gives the results, execution time, and any validation errors that may have occurred.

In your example, I'd have an UpdateCustomerAddressRequest accepted by an UpdateCustomerAddressCommand. Using the terminology from your Onion Architecture post, I use this style of commands to implement my Domain Services layer.