Hi
On the TDD newsgroup Ron made the following comment
--- Ron Jeffries <ronjeffries@X...> wrote:
> On Monday, December 15, 2003, at 4:34:14 PM,
> oncebroke80 wrote:
> To me, TDD is a way of getting a domain model, not a
> way of using a domain
> model.
>
Having read some XP and TDD books and followed disussions and then
now I am in the middle (pg 356) of Domain-Driven Design (DDD) I am
trying to work out how the DDD approach fits in with XP and TDD?
From what I understand of the DDD approach I would be doing some
upfront modelling before moving to test/code/refactor, correct? So
would TDD then intially be verifying the domain model?
There also seems to be an adversion to the term "real world
modelling" in XP circles and I cannot quite understand why? The way
I see at (at least at this stage) is that the domain model comes from
the "problem" domain that comes from a "real world problem".
My gut feeling is that there is some subtlety in this area that I am
missing?
Regards
ShaneMingins
I think there may be some misinterpretations of the intent of the book.
Short pauses for modeling, including a *small amount* of upfront modeling,
is something I often do, but it is neither advocated nor proscribed by the
book. Modeling and implementation are bound together and the iterative
nature of development couldn't be more explicit.
Actually, I'm pretty sure I never use the term "real-world modeling". In
fact, in the introduction I say, "Domain modeling is not a matter of making
as 'realistic' a model as possible. Even in a domain of tangible real-world
things, our model is an artificial creation."(page 3)
Nonetheless, I do expect some XP people will have genuine differences of
opinion with me.
I'd be willing to participate in that thread, could you help me find it?
(And feel free to quote this message there in the mean time.)
EricEvans
I see it this way.
* If you model down to the smallest detail without writing code, then
you run the risk of creating a model we can't implement
* If you model and code as you go, then you get a model /and/ an
implementation, without the preceding risk
The funny thing is this: when I test-drive code, I tend towards a good
domain model, because "quality of domain model" and "loosely-coupled,
highly-cohesive" design tend to correspond to one another, and
test-driving code generally leads me to loosely-coupled, highly-cohesive
designs.
JBRainsberger
"Eric Evans" <eric@d...>
wrote:
> Short pauses for modeling, including a *small amount* of upfront
modeling,
> is something I often do, but it is neither advocated nor proscribed
by the
> book.
That has me confused (sorry) ... so if you do not advocate nor
proscribe this in the book, what is the book advocating with regards
to when and how much modelling to do? Or is it neutral?
>Modeling and implementation are bound together and the iterative
> nature of development couldn't be more explicit.
I still do not understand explicity how you incorporate the
development of your domain model (as proscribed in the book) within
XP and TDD? XP seems to advocate that there is little need for the
formal type or modelling that you describe. Instead it seems to have
been replaced by converstations with the customer.
>
> Actually, I'm pretty sure I never use the term "real-world
modeling". In
> fact, in the introduction I say, "Domain modeling is not a matter
of making
> as 'realistic' a model as possible. Even in a domain of tangible
real-world
> things, our model is an artificial creation."(page 3)
You are correct ... you do never used the term "real world", it is
one that constantly appears in comp.object discussions and a term by
many dislike (and from a certain context I can understand the
dislike).
But as a generalisation, the domain model does come from the problem
space of a real-world problem .... so from that problem space there
are terms and relationships that appear in the domain model that are
derived from the real world. It that a fair statement?
In the shipping example on page 18, is the second design not better
because it does better models what actually occurs in the real world?
Or is there some subtlety that I am missing?
> I'd be willing to participate in that thread, could you help me
find it?
That would be great!
ShaneMingins
See this post from the Industrial XP group.
http://groups.yahoo.com/group/industrialxp/message/881
ChrisGardner
The fact is that you have to have some idea of what you intend to test - what
object and what method - before you can write a test. Therefore at least *some*
thinking about abstractions and responsibilities must precede test writing, even
in TDD. In do way do I see DDD as advocating big design up front. I think DDD
and TDD are perfectly complementary.
RandyStafford
<rstafford@i...> wrote:
> The fact is that you have to have some idea of what you intend to
test - what object and what method - before you can write a test.
Therefore at least *some* thinking about abstractions and
responsibilities must precede test writing, even in TDD.
That's interesting. I actually started the thread Shane Miggins talks
about with EXACTLY THOSE WORDS.
You can find it at:
http://groups.yahoo.com/group/testdrivendevelopment
When I wrote the message I didn't know about this group nor Eric
Evans's book. The domain model I knew about was the one mentioned by
Craig Larman.
The way I see it, TDD is a great way to exercise your domain model,
but you can only find extensions to your model by thinking and
talking to your collegues and customers.
I thought about posting a follow-up thread called "Customer
conversation always takes place in the context of a domain model".
But that was off-topic for the TDD group, and in this group that
statement is far from sensational. ;-)
JohanNilsson
DomainDrivenDesignAndTDD is mentioned on: ThreadView
