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?
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?
Deliver a clear and cohesive user experience?
Deliver something that advances the business strategy?
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.
Favorite Modeling Tools
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.