In the past few years we've seen a huge rise of successful systems built following a Document Object Model
(DOM) type of architecture. By that I mean: open systematized models of complex domains that are easy for applications to specialize and extend in a cooperative manner.

This approach has quickly taken over the tradition libary + statically compiled language paradigm in amazing products like Eclipse, Aspect Oriented Programming (AOP), DOM + Javascript + DHTML, and in Content Management Systems (CMSs) like Drupal.

While we must pay homage to Smalltalk for its unified image based development environment, the most familiar example of the DOM architecture runs inside your favorite browser, using the dynamic trio of DOM + Javascript + DHTML.

The olden days of interface writing is represented by the applet. You combine all your libraries into a single application and download it to an interpreter. This is basically the same as compiling to an image and running the resulting executable on your favorite OS.

Look how different is your browser's DOM based approach. The DOM provides a really rich and functional model of a document, your web browser, which is made available to all applications running in your browser. Multiple libraries can be directly loaded into the browser and build on layers of each others functionality. Applications can add new methods, events, and properties directly to the model. And powerful meta tools like jQuery are creatable because of the dynamic power and regularity
the browser environment provides.

One of the most stunning success stories is Eclipse's DOM type architecture of an IDE. If you would have told me you could make a world class development platform by defining a plugin architecture and then weaving together a myriad of plugins from a bevy of developers, I would have said you are crazy. But it works and Eclipse is now the premier IDE on the market. They succeeded by creating an IDE model, which in my world is a DOM, and then made the IDE buildable by composing parts formed from a generic plugin architecture. That this works so well was surprising to me and very enlightening.

Another interesting application of the DOM type model is in CMSs like Drupal and Joomla. A CMS is like a big web site construction kit allowing you to create your personal idea of a website from the work of 100s of other people. Drupal makes this possible through their module system that allows modules to be composed together. Drupal's role is to provide an open model of what it means to be a CMS, a set of standards about how everyones modules can play nicely together, and mechanisms for composing the modules together in meaningful ways.

For example, forum systems allow readers to make comments on posts. Usually that comment system only works for forum posts, but Drupal takes it one step further and allows the ability to create a comment module that can be attached to any other part of the system, like blogs or polls.

Taking extension yet another step beyond is the Content Construction Kit (CCK) module for Drupal. CCK allows you to create new content types and extend existing content types with new features in a type specific manner that is understandable by Drupal.

For example, let's say I am creating an event system and I want my event to support geolocation. With geolocation we can show events on Google maps and do other cool operations like calculate how far apart events are. Traditionally I would build location attributes and functionality into my event system and this would take a long time, even using a third part library. I would have to change the database, make a module, make it configurable, add theming, and so on.

With CCK I don't have to start from scratch anymore. I can fold into my event the nifty preexisting location module that already exists. CCK will add the location fields, hooks, and widgets into my event in such a way that Drupal can see them as one thing, even though they aren't one thing.

I can take this even further. Let's say I want people to be able to comment on my event, so we weave in a comment module. I also want people to rate the event, so we weave in a rating module. Next I want people to able to submit events like Digg and vote them into a front page, so we weave in the voting module.

A very complex event has been created by weaving in different aspects together in a unified whole. This may sound a bit like AOP but it is much more powerful because what is being weaved together happens within a complete CMS system model. New content types are natively able to take advantage of CMS features like theming, installation, configuration, upgrading, security, user permissions, and database configuration. It's not just AOP's attachment of a bit code at an insertion point, you are creating a niche in a complete interdependent ecosystem.

So what is an event really if it's defined primarily by weaving together different aspects? Here's where we get to the "Identity Based Programming" (IBP) part of our tour. Why IBP? Because all programming ideas these days have to have 3 letter acronyms where the middle letter is preferably a "D" for driven or "O" for oriented. I am really bucking the trend here using "B" for based.

An object is usually said to have identity, state, and behavior. I have always contended an object simply has identity, state and behavior arise from relationships with other objects. For example, the date of an event is usually considered an attribute of an event object and this is part of its state. But in reality the date is in a 1-1 relationship with the object and thus isn't part of the object. This is the same for all attributes of the event, like location, comments, votes, and ratings, along with their associated behaviors. What ties the state and behaviors together is the identity of the event they are in relationship with.

And here's where DOM type architectures and IBP meet. A DOM sets up the system model, the extension points and facilitation protocols. The process of composing and gluing them together to create new applications is what I am calling Identity Based Programming. Applications in Eclipse, your browser, and Drupal are all built this way.

You can say I am not brining anything new to the party and you are absolutely right. I just think it's very interesting to see this approach evolve separately and almost independently in several different application spaces. This approach is fundamentally different than what has gone before, but it's very difficult to pin down exactly what is different. I just thought I would take a stab at defining what is different and to me one of the most important ideas is that identity is what holds all this independent parts together when traditionally we have tried to force these parts to be one whole object.

Biological life works by accretion. Parts keep being added on to existing systems rather than being thrown away and redesigned from scratch. In your brain you'll still find the brain of the lizard, mammal, and the primate. Haman brains were made by adding on. With Identity Based Programming we see the same process happening in building software.

http://radio.weblogs.com/0103955/categories/stupidHumanProgramming/2007/06/20.html#a244