aspose file tools*
The moose likes OO, Patterns, UML and Refactoring and the fly likes Domain driven design VS Test driven design Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Engineering » OO, Patterns, UML and Refactoring
Bookmark "Domain driven design VS Test driven design" Watch "Domain driven design VS Test driven design" New topic
Author

Domain driven design VS Test driven design

Roger Graff
Ranch Hand

Joined: May 29, 2001
Posts: 112
Can anyone comment on how these 2 design strategies can work together? It seems either strategy might lead a system down a different road. Has anyone out there successfully combined these strategies?

-Graff
Sathya Srinivasan
Ranch Hand

Joined: Jan 29, 2002
Posts: 379
Ever since I read the Eric Evans book on DDD and Kent Beck book on TDD, I have started to apply them together. I think they are quite complementary, but on different levels.

I normally tend to use DDD during my analysis phase, which lasts for a few days (2-3) before I actually start developing, to understand the domain and the important concepts. It also helps me provide a feedback to my clients and get a clearer understanding of the requirements.

Once that is done, I tend to use TDD for detailed design, testing, and development.


Cheers, Sathya Srinivasan - SCJP 1.2, SCWCD 1.2, SCMAD 1.0
Co-Author of Whizlabs SCMAD Certification Exam Simulator and SCMAD Exam Guide Book
Andrew Marshall
Greenhorn

Joined: Jul 09, 2003
Posts: 11
I wouldn't call TDD a "design strategy". I would refer to it as a development methodology or technique. It can be used with OO code, procedural code and anything in between.

Andrew
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Originally posted by Andrew Marshall:
I wouldn't call TDD a "design strategy". I would refer to it as a development methodology or technique. It can be used with OO code, procedural code and anything in between.


Have you tried it with procedural code?

Wouldn't it be harder to isolate small units and replace their collaborators with mock implementations in a procedural design?

I ask because I actually find that writing the tests together with the code helps me to better decouple my design.


The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Originally posted by Roger Graff:
Can anyone comment on how these 2 design strategies can work together? It seems either strategy might lead a system down a different road. Has anyone out there successfully combined these strategies?


I haven't read DDD yet. In which way would you say could it lead to a design that's counter to TDD?
Roger Graff
Ranch Hand

Joined: May 29, 2001
Posts: 112
The little I've read about each has lead me to believe that DDD is similar to a top-down approach vs the TDD bottom-up approach.

DDD = design first?
TDD = design on the fly?
[ December 02, 2004: Message edited by: Roger Graff ]
Sathya Srinivasan
Ranch Hand

Joined: Jan 29, 2002
Posts: 379
Originally posted by Andrew Marshall:
I wouldn't call TDD a "design strategy". I would refer to it as a development methodology or technique. It can be used with OO code, procedural code and anything in between.


You definitely can. TDD approach combines design and development together. The tests you write tend shape your code in such a way the the resultant product conforms to a good design.

You can have a look at the TDD book by Kent Beck. He goes through a program to emphasize this point.
Sathya Srinivasan
Ranch Hand

Joined: Jan 29, 2002
Posts: 379
Originally posted by Roger Graff:
The little I've read about each has lead me to believe that DDD is similar to a top-down approach vs the TDD bottom-up approach.

DDD = design first?
TDD = design on the fly?


I would say, close, but not quite. DDD is more at an analysis level rather than at the detailed design level. It helps one to get an understanding of how to form the project from the requirements and also gives a lot of tips on integrating various related projects, effectively interacting with legacy code, etc.

To me, the two approaches are complementary. A good understanding of both techniques leads to a good project.
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
From the little I know about DDD, I'd guess that you would use it to find potential classes, their names and rough behaviour. Than you could use TDD to implement the classes?
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Originally posted by Roger Graff:
DDD = design first?
TDD = design on the fly?
[/QB]


Well, it doesn't hurt to have a rough idea of what the design might look like when starting TDD (actually many descriptions of TDD start with a short design session). After all, to start to write your first test, you at least need to have a rough idea of what kind of class you will test, and what behaviour you will expect from it, don't you?
Sathya Srinivasan
Ranch Hand

Joined: Jan 29, 2002
Posts: 379
Originally posted by Ilja Preuss:
From the little I know about DDD, I'd guess that you would use it to find potential classes, their names and rough behaviour. Than you could use TDD to implement the classes?


Not exactly. DDD mainly emphasizes on getting the terms and terminologies of the underlying domain straight along with the relationships between them.

The idea is to ensure that your program captures the domain knowledge so that when the business client looks at your code (a non-techie), he would be able to understand the concepts at least a reasonable level.
Michael Feathers
author
Greenhorn

Joined: Aug 24, 2004
Posts: 24
Originally posted by Ilja Preuss:


Well, it doesn't hurt to have a rough idea of what the design might look like when starting TDD (actually many descriptions of TDD start with a short design session). After all, to start to write your first test, you at least need to have a rough idea of what kind of class you will test, and what behaviour you will expect from it, don't you?


I agree and I often do that, but I find that the most valuable state of mind to be in when I TDD is the state of allowing myself to be surprised. If the tests lead to a different design, it's important consider it and not to feel constrained by initial design concepts.


Author of <a href="http://www.amazon.com/exec/obidos/ASIN/0131177052/ref=jranch-20" target="_blank" rel="nofollow">Working Effectively with Legacy Code</a>
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Originally posted by Michael Feathers:
I agree and I often do that, but I find that the most valuable state of mind to be in when I TDD is the state of allowing myself to be surprised. If the tests lead to a different design, it's important consider it and not to feel constrained by initial design concepts.


Good point. So you should see a DD design as a rough guideline and allow yourself to deviate from it. After all it seems much more important to me that the code speaks to the developers and is easy to work with, than that it speaks to the business people.

How much effort do you typically invest in DDD? How iteratively, perhaps even concurrently to TDD can it be done?
Roger Graff
Ranch Hand

Joined: May 29, 2001
Posts: 112
The Evans book talks about the importance of linking the Domain model to the code. He also offered a comparision of 2 systems. One had started with a domain model, but the design deviated from it as the development team built the system. The second system was built by jumping into the code w/o much design activity. His conclusion was that over time both systems were a lot alike and eventually unmaintainable.

I think what Evans is saying is that the domain model is of little value unless it grows with the design of the system (changes made during implementation / TDD).

I'm curious how challenging it is to maintain a domain model that accurately reflects both the domain and the actual system architecture.
[ December 03, 2004: Message edited by: Roger Graff ]
Sathya Srinivasan
Ranch Hand

Joined: Jan 29, 2002
Posts: 379
Originally posted by Ilja Preuss:


After all it seems much more important to me that the code speaks to the developers and is easy to work with, than that it speaks to the business people.


In the first chapter of his book, Eric Evans (the promoter of DDD) mentions that one should try to build a "ubiquitous language" - that is, a language that is common to the developers and the business.

From that aspect, the code should be speaking to both developers AND the business folks. The only difference is that they will be giving importance to different aspects of the code - the developer to the implementation and the business person to the class associations.

The advantage in keeping this in mind is that it makes it a lot easier for the business person to understand how the developers are trying to realize the problem and can offer more insight to the relationships.
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Originally posted by Sathya Srinivasan:
The advantage in keeping this in mind is that it makes it a lot easier for the business person to understand how the developers are trying to realize the problem and can offer more insight to the relationships.


Well, yes, but when those relationships are more driven by matching the "business reality" than by the needs of the code, wouldn't that be rather ineffective???
Sathya Srinivasan
Ranch Hand

Joined: Jan 29, 2002
Posts: 379
Originally posted by Ilja Preuss:


Well, yes, but when those relationships are more driven by matching the "business reality" than by the needs of the code, wouldn't that be rather ineffective???


Well, at least at a relatively higher level (not too high, of course), they should be the same and that would be the point.

For example, if you are modelling a shopping cart, DDD emphasizes you have classes like ShoppingBag, Product, etc. instead something techie like ItemCollection, SingleItem, etc.

What DDD wants you to try to avoid is the possibility of having two different models - one for business and one for techies. In my previous project, this actually happened because of some high-level decisions to have an analysis model, design model, etc.

After I read the DDD book and went back and looked at the models, I could see quite a few places where the names could have been changed to make a single model and also to make it more meaningful to the clients who are non-techies.

From a pattern perspective, one of the things that people tend to do is introduce the pattern names (XFactory, AbstractYFactory, etc.). While this maybe justified in some cases, in many others it tends to obscure the model than to clarify it. Also, a good programmer would anyway be able to identify the pattern by the relationships and some standard methods names.
Lasse Koskela
author
Sheriff

Joined: Jan 23, 2002
Posts: 11962
    
    5
Originally posted by Roger Graff:
I'm curious how challenging it is to maintain a domain model that accurately reflects both the domain and the actual system architecture.

I doubt that it's too challenging. The domain model and the software architecture are somewhat orthogonal, in a way, meaning that practically all changes to the domain model force no ripple effect to the system architecture, whatever that is. What does drive changes in the system architecture is if you introduce, for example, a new layer in between the domain objects and the database. That, however, doesn't (generally speaking) affect the actual domain objects themselves.


Author of Test Driven (2007) and Effective Unit Testing (2013) [Blog] [HowToAskQuestionsOnJavaRanch]
Sathya Srinivasan
Ranch Hand

Joined: Jan 29, 2002
Posts: 379
Originally posted by Lasse Koskela:

... meaning that practically all changes to the domain model force no ripple effect to the system architecture, whatever that is.


I don't think so. In fact, every domain change would invalidate the supporting system, thereby needing a change in the system to reflect the change in the domain.

For example, if the concept of MONEY changes in an accounting system because everyone reverted back to Barter system, I would think that the program that works on money would have to change as well. Otherwise, the program will no longer be useful!
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Originally posted by Sathya Srinivasan:
For example, if you are modelling a shopping cart, DDD emphasizes you have classes like ShoppingBag, Product, etc. instead something techie like ItemCollection, SingleItem, etc.


Oh, I fully agree that if I find a class in a system that closely relates to the real world concept of a product, that it should be named that way.

The ShoppingBag example already is a little big trickier, as it really isn't a real world entity in the case of an e-shop, but "just" part of the methaphor used. I agree that in general it would be beneficial for the business people and the developers to speak the same language, and therefore use the same methaphor, of course.

But I'm nevertheless sceptical of letting business language drive the system structure too much. In Uncle Bob's Bowling Game Example, should they have introduced a Frame class consisting of Throw's, just because that's how the "business people" would have thought about it?
Lasse Koskela
author
Sheriff

Joined: Jan 23, 2002
Posts: 11962
    
    5

Lasse: ... meaning that practically all changes to the domain model force no ripple effect to the system architecture, whatever that is.

Sathya: I don't think so. In fact, every domain change would invalidate the supporting system, thereby needing a change in the system to reflect the change in the domain.

For example, if the concept of MONEY changes in an accounting system because everyone reverted back to Barter system, I would think that the program that works on money would have to change as well. Otherwise, the program will no longer be useful!

That's true. Note that I said "practically all", not "all". Most changes in a domain model -- according to my experience -- are such that you may need to add a bunch of methods to your data access layer etc. but you don't need to change your architecture.

Obviously one should never say never...
Lasse Koskela
author
Sheriff

Joined: Jan 23, 2002
Posts: 11962
    
    5
Originally posted by Ilja Preuss:
But I'm nevertheless sceptical of letting business language drive the system structure too much. In Uncle Bob's Bowling Game Example, should they have introduced a Frame class consisting of Throw's, just because that's how the "business people" would have thought about it?

Yes. I think so. In the end, those are the concepts that the developer uses to wrap his mind around bowling as well.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Domain driven design VS Test driven design