In regards to TheValueOfDomainModels, RichardHenderson wrote:

''I have a problem with people using the logical domain model as the sole driver of the implementation (top-down only programming). The model rarely considers implementation issues that might affect it. Thus these are often produced at the end after the original has been hacked up to match what actually worked. -- RichardHenderson.''

I'm not a fan of forward-engineering from a CASE tool either. What has worked for me in practice is to scratch out a quick class diagram on a whiteboard (preferably a writeboard), just so you can work out the right names for the abstractions, and their relationships to other abstractions, and maybe important attributes and responsibilities, and then go off and code them. Of course they adjust themselves over time - responsibilities move around as use cases are implemented, new relationships appear, etc. If somebody wants to know, after the fact, how the thing is put together, then it can be reverse-engineered with Together/J or something.

------

I have also a problem with people with a top-down approach. I hate CASE tools, I like white boards, and I like papers and pens (I mean real pens not the ballpoint kind of). I need to know of a sketch before I start coding. The sketch can be even in my mind.

What I hate about CASE tools and their idea of object models is that they lead me to a ''fill in the method body and you're done approach''. I don't know, maybe my experiences with CASE tools were limited, and the first impression was bad. The only good impression was that TogetherC++ is quite very capable of reverse engineering.

The big problem with CASE tools and with UMLs is that they don't support ''relations'', the minute I draw a link from one class to another, it starts buzzing me (association, composition, aggregation ?? association as private field, association as java.util.Vector, association as array, association as ...), I can't just tell the guy to shut up, ''It's a relation, OK? I'll figure out later, maybe I have a key and I'll make the connection through a cache engine or something.''. ''No, sorry, you can't do that buddy, you have to tell us what it is and make sure it's written in stone. Make sure it's not something like Parent Children.getParent(), because we cannot make the distinction between a method that creates a new object, and a method that makes the connection with an existing one - revealing an implicit relation, make sure you have a pointer or an array of pointers or something that we do understand (like Java Standard Collections or C++ STL)''.

Why the heck can't I have something like an Abstract Class Diagram, is there something that I don't understand, or am I limited by my terrible prejudices against UML, why do I have to operate on a domain model (as far as I understand class diagrams are the closest thing to ''describing'' a domain model) -- CostinCozianu

----

Costin, I'd be interested in your thoughts on MartinFowler's discussion of "perspectives" on domain modeling in UmlDistilled. I think what he describes as the "conceptual perspective" is what you mean by an "abstract class diagram". To Smalltalkers, the term "domain model" has historically meant an "implementation perspective" domain model - namely, code - of classes - like Person, Employee, etc. - and not, necessarily, a class diagram. -- RandyStafford

I'll try to get a hold of the book, though in my nearest bookstores I couldn't find it, therefore I couldn't submitted it to my BookTestUnit, I'll keep trying though. I don't like class diagrams either, since they don't offer me much more than what I can express in any decent IDE through writing code. Sometimes is important to have a higher abstraction, before you start coding, therefore I do sketches on paper, it's a lot faster than using any UML tool. With that abstraction in mind, I do just in time design, I choose the best solution that look fit to me, the minute I have to type the code.

I have and I liked MartinFowler's AnalysisPatterns. Although the book is very good I was a bit disappointed when I found the discussion extended too much from analysis to design to implementation, without any caution from the author. An expert reader should have no problem to distinguish between the different levels, but a beginner will have problems identifying where analysis ends and where it begins.

Why I think an ''implementation perspective'' is too close for defining a domain model? Sometimes, because the lower level of abstraction (''should I use a Vector, or a Hashmap, etc ?''...) you don't get to see the forest, because you only see the trees. For example when I was in the eighth grade , although I was good at algebra, I could stare for hours trying to decompose a polynomial like: ''X^4+16'', because I didn't have a larger perspective, I didn't know complex numbers, I was too close to my dear real numbers polynomials. Once the perspective gets better the problem is a snap.

This is not a metaphore, but merely a comparison, so I hope I can get away with it. However, what I described is a repeating pattern in mathematics, a repeating pattern in algorithm construction and analysis: ''you have to step a little back from the immediate concerns at hand, and have a look at the larger picture''. And I found it to be a repeating pattern in my experiences with developing software. - CostinCozianu