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

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.

1 comment

  1. 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.

Comments are closed.