All three double D's are about how to approach your design. What drives you, how do you get started, what's your angle? How do you decide which classes to use? What are the dependencies, etc.
Domain Driven Design (DDD) focusses on the core model (the domain) and tries to keep other stuff like UI's and databases separate. You can google for the site and the Book from Evans. I'm not too convinced it offers much new, but maybe I'm influenced too much by the worst presentation of QCon (Filipe Rodrigues, better luck next time man). I also have a graduate which can't explain to me what the big deal is.
Test Driven Development (TDD) is the one I'm most familiar with from my XP classes. First code your JUnit test and then code your class to make it pass.
Behaviour Driven Development was new to me. I noticed they were talking about BDD in connection to Ruby (RSpec), but just stumbled across a nice page that explains the concept: http://dannorth.net/introducing-bdd. Even if you don't use BDD, it gives some really nice tips for TDD.
Abonneren op:
Reacties posten (Atom)
.jpg)
7 opmerkingen:
I might be talking about a completely different thing here, but I can see some advantages in DDD. At least to prevent, or minmize the dependency, or more yet mingling with your UI and persistence stuff. Since in most business cases it's the goal, or as you state core, of the whole application. I think it's very usefull to have the business logic in one place without too much other stuff mingling because it's easier to maintain that way. I see an advantage in being able to prevent code for persistence for example in your domain model, since it is in my opinion just a secondary task or process. Of course persistence is important but apart from that doesn't have a thing to do with your business logic itself, it's facilatary so to say.
I have been reading a lot in the book by Martin Fowler (Patterns of Enterprise Applications) and some of the ideas are from that book. I think things like AOP can really help with this (yes I just read your article in the Automatiseringsgids ;-)). Apart from that i don't see why TDD would be a whole different thing, it could be a complimentary thing as i see it? But i guess your talking about choosing one method of approach instead.
Kind regard from one of your students ;-)
@Anton:
We probably just agree. The points you mention about DDD are indeed good points. It's just that I don't see what the hype is about, it's all known ideas with a new label.
As for AOP, it's indeed useful, but I don't expect it to become mainstream. Like, in 10 yrs time we would all program AOP as we do OO today.
DDD isn't necessarily new, but I think there's more to it than simply separating concerns. It's about ubiquitous language, embedding business knowledge into the code, conceptualising a domain and creating a rich model. I think it's pretty orthogonal to TDD, but maybe BDD could be seen as an extension of the ubiquitous language to testing?
The focus for DDD is very new, and hinted at by the last post. DDD is more about people and communication than it is about technical issues and separation of concerns issues. They are just things that are necessary to create a good DDD design.
DDD is about getting IT to shift their often too technical focus onto the business, the language of the business and how that business works. Without this focus, the core business logic justs ends up being subsumed within the web of technical architectures and frameworks.
There is a clash between DDD and TDD. TDD is about having testing driving your design, creating the simplest design possible to solve the current problem. When developing the domain model, this simplest solution may not accurately reflect the business, or it may compromise the ubiquitous language.
Therefore, when modelling the domain, it is sometimes necessary to take a test first DDD approach. Note, that your notes on TDD actually define a test first approach. There is much more to Test Driven Deveopment (Design) than just writing a test first. I mentioned some aspects in the previous points.
Actually, I slightly re-thought the previous remark. We can do TDD to drive our code. When we do this, our tests become the specification for the system, or in this case, the domain model. All we need to do now is drive the specification from the domain. So we have domain driven tests, and test driven development, I guess resulting in DDTDD ! :)
A very good read and critical and unbiased comments, thank you. I guess industry is now overwhelmed with new names for what is already in practice, we need more interaction between research, intellectual work and industry to put all this stuff together, a very good hype is an IT sales guy talking about DevOps just sell services.
Een reactie posten