Views
- State: published
Adaptive Object Model Architectural Style
|
|
(of Gang of Four fame) has been writing for a couple years now about "Adaptive Object Model Architectural Style", I quote from one of his papers "We call these systems "Adaptive Object-Models", because the users' object model is interpreted at runtime and can be changed with immediate (but controlled) effects on the system interpreting it. The real power in Adaptive Object-Models is that the definition of a domain model and rules for its integrity can be configured by domain experts external to the execution of the program."
Note, this may be nothing new for some, however, I find it extremely worthwhile to read the writings of someone who has been researching this topic for a long time, furthermore I'm always looking for good conceptual models of what I'm presently dabbling in. Just like patterns made explicit what many OO developers had known implicitly, Johnson pin points a paticlular archiectural style that is of extreme importance for anyone developing business systems. Furthemore, his research tells you that to satisfy your business users, that is to give the business analysts the control that they need, you have to build OO systems this way.
If you got just one reason why EJB is flawed, this has got to be the one, you can't build systems for Enterprises at the same time take away control form the business stakeholders. In an earlier article, I said that the domain object model should be preserved at all times, however, in addition to that, it should be painless to change the object model and ultimately the business rules.
There are many instances of Adaptive Object Model (AOM) found in our open source projects, OFBiz Entity Engine is one that comes to mind, another is DynaBean. For JCP approved standards you find JMI and JMX as interesting incarnations of AOM.
Clearly the AOM style is very different from the OO style that we typically know. What this implies is that Plain Old Java Objects (POJO) and targeting it to different architectures using Aspect Oriented Programming (AOP) may not be the right approach. That is, not the right approach for "Programming in the Large". The synergistic approach then is to start with an AOM and then apply AOP.
Last modified 2003-07-30 04:14 PM



You hit the nail on the head with that one. This seems to be the big issue with aop research, it is so focused on dealing with behavioral complexity, and not concerned at all with the structural complexity of domain objects, which is the biggest problem that enterprise systems face.
In the microsoft, .net world its widely believed that you should not try to create "business objects" at all, because so many attempts to create pojo-based domain models have collapsed due to the inability to model all of the different variations cleanly. Most of the time this leads to badly scattered domain logic.
I've had huge success following ralph johnson's adaptive object pattern though. Many types of domain objects can be created without even being represented as classes, and can implement complex behaviors which are specified entirely by the structure of the object itself. When special case behavior is needed, it is easy to create adapters to the underlying dynamic object.
Brian http://www.brianmandersen.com/blog