Dynamic Object Model is an architectural style "discovered" by Ralph Johnson around 1997. The application of this approach to Systems Development is more commonly known by the name of Adaptive Object Model.
The word "discovered" is used because in his paper, "Dynamic Object Model" at st-www.cs.uiuc.edu 
, Ralph referred to an earlier instance where another person named related work as a "Type Instance Pattern". Ralph himself had referred to this style as "User Defined Product architecture" before he published the above paper.
Some of the other points made in the paper include:
An implementation based on Dynamic Object Model is interpreted and this is one of the costs of flexibility of "dynamic objects". Dynamic objects provide a way of defining new types without additional programming. In a typical implementation "type defintions" are stored in databases so new types can be deployed by adding to this database.
The use of this architectural style has other costs such as the need to build "support facilities" for users of the resulting application. He suggests this is particularly important if the system is to be maintained by end-users and not system/application architects.
Other notes
I have located a Semantic Web reference to this at www.w3.org
So I am hoping other Wiki Readers may find this Gang Of Four paper of interest.
-- David Liu Nov05
Does this material merit its own entry in the Programming Paradigm list? Or is it a category within Reflective Programming?
Any relationship to Table Oriented Programming? The paper mentioned a component called "Strategy Pattern" that look like code / algorithm persisted in tables, in manners ?similar to Table Oriented Programming
I have this pattern. I used it in 1994 to build an investor demo for Riverton Software, where the client needed to create and then instantiate new kinds of business objects and activities at runtime. Infinium Software, then known as "Software 2000", used this pattern to build "Infinium", a UI generation tool for their AS400 HR, GL, and other db products. I hadn't looked at it from the perspective Ralph describes - I always thought of it as turning the Smalltalk meta-structure crank one more time around. The use of a separate "Properties" object (generally a dictionary) has some very appealing characteristics, especially in a production environment. Dynamically-generated "member accessors" can, at least in Smalltalk, turn out to be much faster than you might think. As it turns out, these dictionaries can often be replaced by dynamically-generated Smalltalk classes without using the compiler. The trick is to recognize that ALL of their functionality will be accessor methods, and the resulting Compiled Methods can be copied from a single template; the required literals can be written in the literal frame by the generation method based on inspection of the slot name. As in many things, once you know what you want to do, and make it work, the performance optimization can then follow. -- Tom Stambaugh
Not to be confused with modern web browsers' Document Object Model.
See original on c2.com