High Time to Remodel Object Modeling?

I don't know if it's just me but there seems to be very little progress in the object modeling front as of late. Before the turn of the century, how you did object modeling was tied very closely with development methodology. Some of the more well known methodologies included OMT by Rumbaugh, Booch method by Booch himself, Use Case Driven design by Jacobsen (all 3 to be combined later to be Rational Unified Process or RUP). Other well known methodologies were Responsibility Driven Design by Wirf-Brock, you had Shlaer-Mellor and Role Modeling by Reenskaug.

Most practitioners are familiar with the Use Case Driven methodology of Jacobsen or the OMT Domain Model driven methodology of Rumbaugh and Booch. Unfortunately, very few are aware that there are other ways at discovering and designing an object model. Responsibility Driven Design focused on balancing and distributing object responsibilities across classes, Shlaer-Mellor focused more on a State Machine Driven approach and Role Modeling focused on the different Roles an Object may adopt in its lifecycle.

Good or bad, there was eventual consolidation. It had its benefits, there was greater standardization and therefore less confusion in the marketplace. However, with standardization comes ossification, that is, the object modeling techniques that sprung out of RUP has remained quite stagnant over the years. The focus then turned towards Design Patterns which in a nutshell is a consolidation of our collective design experiences. Then the focused turned again, where the consensus that big up front design was flawed and a more agile iterative approach was critical to success. The new emphasis moved away from the modeling activity itself and moved to more process oriented activities such as agile development. But object modeling itself is orthogonal to agile development. You do XP, Scrum or FDD and have a pick of what's out there.

The problem however with agile methods like XP is that modeling has been completely de-emphasized. Your code is your model. Your model is discovered via Test Driven Design (TDD) in a bottom up manner. It is an effective approach, however there's a lot more to good modeling than conjuring up new classes as you build test cases. There is value taking a top-down approach over a bottom up approach. There is value is seeing the forest instead of only the trees.

It is unfortunately that the need for formulating a solid domain model is on the wane. The current trend is towards informal folksonomies. Systems that build their models on demand and are built from the incremental contributions of users and their communities. It is a compelling approach the flies in the face of big up front design, however revolutionary and compelling designs are rarely as a result of the creativity of the masses. Object modeling remains relevant because containing entropy requires good abstractions.

Since the ossification of the RUP standard, there have been several new abstraction technologies that have become more common. The main tenants of object oriented programming, that is encapsulation, polymorphism and identity have been augmented with new more powerful mechanisms that work at the meta level. Introspection has provides us with component models and ability to define classes on the fly. Annotations permitted a base language artifacts (i.e. classes, methods, attributes etc.) to be decorated with new semantics. Aspects provided a non-intrusive mechanism to augment behavior. Finally, Meta-programming provided the mechanism to change the behavior of an existing system in a dynamic and sometimes unsuspecting manner. It is high time to remodel object modeling.

If you look around, almost everything developed today uses object oriented programming languages and techniques. However, although they do employ the same artifacts, modeling infrastructure and modeling a domain are different enough that they require different techniques. TDD and Design Patterns are extremely effective in developing infrastructure, however it isn't enough for domain modeling. The intention of Domain Modeling is to create a model that not only reflects a customer's reality but also exposes new perspectives and points of innovation.

Take for example 'Color Modeling', not may object oriented developers are familiar with the notion that there are generic domain neutral patterns that repeat themselves over and over again. The recurring patterns are identified as Role, Moment-Interval, Person/Place/Thing and Description. Astonishingly enough, it appears that this is all that's ever needed! I was dumbfounded that the book "Domain Driven Design" makes no mention of these patterns. The book "Data Model Resource Book" which has an extensive collection of data models. In these models you'll find several recurring patterns that mirror the Color Modeling patterns. My point is that, there a distinct patterns in domain modeling that we shouldn't be ignorant of.

So let's say we use as a starting point these 'Domain Neutral Patterns' and then employ the latest meta-programming technologies such as Annotations and Aspects. Would we arrive at something eerily similar to Qi4j? Qi4j is dubbed as a 'Composite Oriented Programming' and is based on some intriguing principles:

• Behavior depends on Context
• Decoupling is a virtue
• Business Rules matters more.
• Classes are dead, long live interfaces

Qi4j incorporates a lot of the features of earlier techniques like Fluid AOP, Object Remodularization and Active Object Modeling. It is certainly a promising evolution in providing a richer and more maintainable domain models. This development may also turn the spotlight back to object modeling, where in the past couple of years that attention has been sorely lacking.