Ce diaporama a bien été signalé.
Nous utilisons votre profil LinkedIn et vos données d’activité pour vous proposer des publicités personnalisées et pertinentes. Vous pouvez changer vos préférences de publicités à tout moment.

DDD eXchange 2010: Gojko Adzic on DDD, TDD, BDD

3 568 vues

Publié le

Domain Driven Design is often misunderstood as something that advocates a lot of upfront design and at odds with the evolutionary design principles of test driven development. In this presentation, Gojko Adzic will talk about reconciling the two approaches and getting the best of both worlds, and how DDD ideas play a crucial role in behaviour driven development.

Publié dans : Technologie, Formation
  • For more details and podcasts from the DDD eXchange 2010 go to http://skillsmatter.com/event-details/podcast/ddd-exchange-2010
    Voulez-vous vraiment ?  Oui  Non
    Votre message apparaîtra ici

DDD eXchange 2010: Gojko Adzic on DDD, TDD, BDD

  1. 1. The three amigos @gojkoadzic
  2. 7. Effective models require a bigger picture … but KISS and YAGNI say don't... avoid BDUF
  3. 8. … feature injection gives us right-size chunks
  4. 9. Things can blow up during modelling... <ul><li>… but domain experts often can't decide on scope </li></ul>
  5. 10. ...collaborative specifications cause things to blow up quicker
  6. 11. DDD advocates a ubiquitous language... … but it's very hard to ensure consistency
  7. 12. … evolve with specification workshops, enforce with tests
  8. 13. Domain experts don't really understand low level stuff <ul><li>.... but where do we stop working with them? </li></ul>
  9. 14. ...BDD outside in boundaries ...TDD emergent design to flesh out details
  10. 15. Emergent design leads to too much inconsistency <ul><li>… especially on big teams and across boundaries </li></ul>
  11. 16. … use DDD building block patterns as guidelines
  12. 17. Effective iterative design requires effective regression testing … but unit tests are bound to a particular design
  13. 18. … business oriented specifications do not change
  14. 19. We need to capture our models and what they mean <ul><li>… but code is too low level and UML gets old very quickly... </li></ul>
  15. 20. … live specification can explain our models and dynamics
  16. 21. Emergent design advocates constant refactoring <ul><li>… but in larger teams, refactoring cross cutting concerns can cause a ton of issues </li></ul>
  17. 22. … bounded contexts help us coordinate changes
  18. 23. Recipe for success <ul><li>Use strategic design to decide what to build </li></ul><ul><li>Use feature injection to get the scope </li></ul><ul><li>Evolve a ubiquitous language with specification workshops </li></ul><ul><li>Establish guidelines with collaborative high-level domain design </li></ul><ul><li>TDD design below, respecting DDD guidelines </li></ul><ul><li>Use context mapping to facilitate cross team collaboration </li></ul>
  19. 24. Questions? <ul><li>http://gojko.net </li></ul><ul><li>@gojkoadzic </li></ul><ul><li>[email_address] </li></ul>