Home >

Domain-Driven Design (DDD) Immersion Course – Part #6

4. March 2010

This section of the course on day 4 covers how to incorporate DDD into agile , which raises the common question of just how should design be done in iterative and incremental development.

DDD Immersion Course - Blog Series Summary

Here are links to the entire series.

  • Part One – Introduction. What is DDD? Ubiquituous language? a Model?
  • Part Two – Building-Block patterns (eg. Aggregate. Domain Event. Creative Collaboration etc)
  • Part Three – Strategic design – Bounded Context and context mapping.
  • Part Four – Strategic design (continued) – Core Domain
  • Part Five – More on supple design (Specification pattern). Implementation concerns. Discussion.
  • Part Six – Design and agile.
  • Part Seven – Final. Course takeaways and other thoughts.

Some (Somewhat lame) Comments Eric Often Hears About Design and Agile:

We should do a nice design, but we just don't have time

This is just a poorly formed thought. It just doesn't make sense.

Modeling and design take extra time, but they pay off in the long run.

Used to believe this, but now rejects it.

Modeling and design is often the quickest path to the goal. But what is your goal?

  • Implement this user story?

    • If this is your goal, design is not going to help you. Design and modeling are hardly ever the path to this goal.

  • Complete a releasable set up stories with an acceptable level of bugs?

  • Deliver a release that the team can continue to extend in the next release?

    • With each successive release you get less and less value, for projects with this kind of goal modeling and design can help and get you to it faster.

  • Deliver a clear and cohesive user experience?

    • If you look at really successful products they usually have a very clear and coherent user experience.

  • Deliver something that advances the business strategy?

    • Some of the choices around ordering the backlog in agile address this, and DDD helps with this goal.

Good goal: Drive a design from a model.

Unfortunately, people often relate this goal to an upfront analysis phase. 

Models are distilled knowledge. At the beginning of a project, you are as ignorant as you can be. Don't lock in that ignorance.074

Favorite Modeling Tools

  • Whiteboard

  • (x)Unit

  • Our mouths and ears

DDD can be undramatic. People perceive modeling as this big thing. Or big tools with UML. DDD is woven in, and is very undramatic. And can fit in easily with the agile cycle.

  • Walking through concrete reference scenarios.

  • Creative collaboration with domain practitioner

  • Refinement of the UL and therefore the model

In agile all too often, and in TDD, we get so focused on the answer, we don't take notice of the things that don't make sense. Typical scrum projects get into trouble because they don't pay attention to modeling.

At this point pay attention to the model so you don't slow down over the next few days. Not months, not releases. But days.

Challenge your assumptions.

Although DDD is very agnostic about process, in practice Eric uses a very particular process with his clients. It starts with knowing when to model. You don't need to model all the time. That type of fine-tuning of the model happens day-in-and-day-out, and doesnt' really challenge any of the assumptions.

Have a model, then challenge that model with a new scenario. In parallel with refining the scenario, we create model ideas. This is also an exploratory process. Not trying to produce production code, but explore design options and risk. Try to find a scenario that really explains the flaw you found, and work through the process again.

Pull useful bits into whatever kinds of documents you might want to create (mine and refine).

This may go for an hour, or you may come back to it days in succession. But you would not typically spend a whole week on it. Maybe if you need to explore a new subdomain or area and kick off some new ideas.

Continue on to  Part Seven – Final. Course takeaways and other thoughts.

Go back to Part Five – More on supple design (Specification pattern). Implementation concerns. Discussion.

Comments (2) -

3/5/2010 12:04:54 AM #
Paul, your posts on the courses are valuable for those that did not attend, and I especially like the quotes you report from Eric. I'll come back to this series for reference when in doubt, as a complement with other sources such as the book and the ddd website.

Thanks for sharing.
Cyrille
3/5/2010 4:47:13 PM #
Thanks so much Cyrille. I'm glad you found the material valuable.

I really enjoyed your blog posts on where to find inspiration for supple design (lot's for me to digest there), and that the quote on symmetry from Eric was helpful there.

Paul.
Comments are closed