Object Oriented Models, even when very loosely coupled and very highly cohesive, can become quite complex over time. Also, when developing applications from scratch, it can be difficult to encapsulate all the requirements of the customer into one coherent model. In this article, I will share an interesting proposal to the architecture of OO-models that makes developing large systems highly iterative: You can completely develop one piece of the application, without having to take future extensions into account. This is ideal when you're using an Agile development method, such as SCRUM, where you have to show the customer a working application at the end of each iteration.

This approach is not so much something I invented after a long train of thought, though. Actually, it is something that I discovered while developing applications and that proved itself very useful even before I thought of it as a generally applicable pattern. Now, I try to use it as much as I can in every new model I design and it really makes developing applications so much faster and cleaner. I want to warn all the OO-purists out there: you may think that this approach is extremely wrong and that I am out of my mind, but bear with me! I will discuss the consequences of the approach later on.

You can read the entire article at: http://www.zenbi.nl/en/blog_the_iterative_reference_model.php

I taken a quick look at your article.

Probably I'm missing something but, in my opinion what you call traditional approach is totally wrong: you couldn't model one-to-many relationship in a many-to-many way.

 

To which relations do you refer? There are two one-to-many's: Company -> Contact and Company -> ContactMoment. There's one many-to-many: Contact -> ContactMoment In the Iterative approach, basically the one-to-many's become many-to-one's, while the many-to-many stays the same.

Without having read your article thoroughly, it seems roughly similar to the topic of this book:

 

http://www.amazon.com/Emergent-Design-Evolutionary-Professional-Development/dp/0321509366

Interesting article and I'm glad you took the time to discuss the positives and negatives!!

Thanks! There are always upsides and downsides and not all usecases lend themselves for this approach. But I'm glad you liked it!

The 'new' approach you are writing about is the traditional one ;-)

Not from what I've seen... But I'm relatively young, so I haven't experienced the really old stuff...

I do agree that sometimes, a return to the "old way of doing things" is an improvement. Sometimes, thanks to new technological possibilities, old architectural patterns become valid again.

I'm not sure i understand the solution. You merely seem to be giving weight to one domain object over another.  What if you have a Customer, Account and Order objects and their associations.  Which one would you pick to start with?  Also it doesn't seem to address parallel iterations.

Sony

I have to agree with other commenters, your "new approach" seems the traditional one to me. It's how the Hibernate docs tell you to model this type of relationships.

I also think you may be confusing the domain model with the relational model. IMO the direction of arrows in the domain model has little to do with the database schema, and everything to do with how you use the relations *in your code*. You seem to be conflating the two...

Also, in your "traditional" example, why is every relationship modelled as many-to-many in the DB? It seems overkill, and may be the source of the problems you later spot.

Thanks for the opportunity to clarify this!

There are basically two reasons why I use join tables for one-to-many relationships:

1) I don't want to "pollute" domain tables with list indices, as I said in the article
2) Suppose you have a one-to-many relationship Car -> Wheel. You suggest that a Wheel should have a foreign key to Car. But now we are going to add the one-to-many relationship Bike -> Wheel. Now what? You're stuck. When you use join-tables, you simply add a table for the new relationship.

In the Iterative model, the one-to-many becomes many-to-one, so in that case, you *can* do it with a foreign key. But as I said in the article, you should only apply this approach when applicable. In the Car, Wheel, Bike story, it is clearly not the best way to go, but there are a lot of cases where it is.

I definitely don't confuse the two models. To quote my article: You should never ever let your OO model influence your relational model and vice versa! They should be independent and the mismatch should be solved at the ORM layer! My main motivation for this approach is the iterative nature of it: the ability to complete one part of an application without having to think of the next part. The positive consequences on the DB-side are just an additional benefit.

I'm going to update the article with this, so that other people won't make the same misunderstanding.

Just read your article and when I saw the 6 tables that you created out of the model, I had a total "QUE?" experience. Where in the world did these tables come from? Basically it are 3 entities and 3 M-N relationships, AFAIK not what was to be modelled and a totally unnessecary performance hit on multiple area's (as you point out). 

The second datamodel OTOH is as I got tought some 20 years back during my IT study and how I still model my relational schema's today.

So I'm not sure what that first thing was, but I'd suggest to put in an big bin, screw a lid on it and stick to the second approach :-)

Basically, I explained this in my previous post. I have updated the article with this, because a lot of people ask me this question :-)

Strange article ! 1- The transformation of a conceptual domain is not linked to the navigability of the associations ! 2- The transformations rules exist. And of course, if you've more than one 1-N associations to a class A, you're OBLIGED to use a "join-table", it's not something new. Iterative should not be used "à toutes les sauces" !