Adaptive Object Model Architectural Style.
Ralph Johnson (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.
[::Manageability::]
An interesting read. OO is a great way to build software but I do think we tend to look at things with OO rose tinted glasses sometimes. Things like object databases and distrbuted objects can often be a leaky abstraction. Sometimes we should just treat data as just data.
Typically data comes from databases or remote services which requires runtime marshalling and typechecking anyways - so much of the compile-time benefits of using typesafe objects are often moot. It can often simplify development, particularly of front ends, to keep the data seperate from the business logic and use something like DynaBeans as an AOM style API to your data.
