Page 1 of 1
Methodology for domain development
Posted: Sun Apr 19, 2009 4:29 am
by matthijs
Until recently, whenever I was thinking about coding something, I was mainly concerned with the implementation side of it, the how. But slowly, as the how becomes somewhat less of a difficulty I start to think more about the way the different objects should look and interact with each other. Without being too concerned about the exact way things have to be coded to work.
So what are you guys doing/using, in a practical sense, to develop your domain models?
Do you just start coding classes and writing methods and see how things develop? Do you sketch stuff on pieces of paper? UML diagrams in a software program? Cleaning up my desk I discovered a pack of small cards used for note taking and was thinking they would be very useful to sketch my domain models on. It's easy to write things down, move around the cards, have a good overview of all models and method names, etc. Much easier then looking at a small screen in a text editor and switching between different screens anyway. So each card would look something like:
Code: Select all
Article
- name
- title
- author
+ insert
+ update
+ findBy
etc
The reason I'm interested in the methodologies being used is that from my experience so far that as soon as you have a certain amount of classes written, it becomes much harder to keep a good overview of everything. Method names might not be consistent anymore, some code is repeated in more places, etc. On the other hand, if method names are consistent, classes are clear in their responsibility, coding suddenly becomes a lot easier
Re: Methodology for domain development
Posted: Sun Apr 19, 2009 6:05 am
by Yossarian
I used to use cards too, not for long though.
I find that using TDD means that the method names seem to evolve on their own ... and as the roles move around classes, and groups of classes, so does their specification and relationship.
It is hard to explain but its as if I am refactoring as I go, and the class/method names cannot be foreseen and indeed even when I have settled on what an object does, its scope, responsibility etc then I spend ages with my head in a thesaurus trying to nail that in a word or phrase.
I do have to start somewhere though, and that generally tends to be an A0 size piece of paper on a drawing board, and colored pens and markers.
Funny, but I noticed on my current project I am starting to draw what I can only describe as "black boxes" with vague names, all I know is roughly the types of information to be handed out and gotten from these boxes - the actual implementation is way too far off to even think about method names.
Have you come across CRC cards (
http://www.c2.com/doc/crc/draw.html ) yet?
TDD tutorial.
http://www.lastcraft.com/first_test_tutorial.php
Re: Methodology for domain development
Posted: Sun Apr 19, 2009 11:06 am
by matthijs
I was indeed meaning something like the cards you link to.
Yossarian wrote:I find that using TDD means that the method names seem to evolve on their own ... and as the roles move around classes, and groups of classes, so does their specification and relationship.
Do you mean that you often change the method and/or class names?
My idea is that TDD works very well, but you are always working on an isolated part of the application. So say you're TDD-ing some widget class. You figure out a method name save($data) with a single array parameter. Now many weeks after this you're working on a user class and come up with a method insert($par, $par2, $par3). As you see, not that consistent with the other one, even though they basically do the same. If you had everything on paper in an overview it's easier to spot the inconsequent stuff.
Yossarian wrote:I do have to start somewhere though, and that generally tends to be an A0 size piece of paper on a drawing board, and colored pens and markers.
Yes, that might be an idea as well. With cards it's easier to move around stuff I guess.
Recently I had a very complex method (running into hundreds of lines with many many if else loop nested) which was just impossible to get right. Getting everything on a piece of paper, drawing a simple diagram of questions with yes/no answers and arrows did help a lot to discover better ways of coding this.
Re: Methodology for domain development
Posted: Mon Apr 20, 2009 4:23 am
by Yossarian
Do you mean that you often change the method and/or class names?
Yes. Because the relationship of each class to its immediate callers/callees is not clearly defined enough when I start out. I haven't thought out if it is part of a larger group which may evolve into a factory or strategy, or may end up just being a one-way device which does one thing.
Giving a class a name before you even know what its exact job is, is just too limiting - I tend to start trying to make it class which fulfills its namesake, ("Hello, my names Brown, Brown by name brown by nature").
I do know the job that has got to get done, and generally have an inkling of what it should not do. But thats about it. I might be doing it wrong though ...
Re: Methodology for domain development
Posted: Tue Apr 21, 2009 11:16 am
by gregor171
I use cards and process draw. Full wall of them. In the process I try to isolate "black boxes" with unique functions and the one with settings or related but related content (as article and article_comment). I found a great source of ideas, how to get trough architecture by using patterns. They allow me to isolate parts of code more without losing their cooperation. In time class names and functions do not change that often.
A kind of domain model is good and it acts as application level settings and more. Especially when you serve multiple pages.
TDD I don't quite get with. Perhaps I should take more time to study them. Never the less I use a kind of watch classes that can serve as live debug as well.