How does DDD fit with agile?

- [Instructor] DDD, of course, works very well with Agile. We've seen one reason, which is the collaborative working environment. If you look at the Agile manifesto and it's principles, it's right there in the manifesto. "Business people and developers work together daily "throughout the project." And DDD is very much a collaborative process in this way. In other words, you cannot do DDD-style design if you don't have business people in the room. It is always a collaborative process, and you'll find, as an architect, that the business people will be contributing more to the design of your code than technical people will. Because remember, if you analyze the domain, you are analyzing the code. The structure of the domain is the structure of the code. So the business person's notion of the way the domain works, is telling you exactly how the code has to work. So we link DDD into the Agile manifesto, but the processes associated with Agile also link very nicely into domain-driven design. Agile is based on the basic work loop called the inspect and adapt loop. The basic idea is that you make a small change, then you release it. You assess what you've done, usually by talking to your end-users, and then you improve it based on the feedback that you get. That's cyclical process is really Agile, 'cause all of the other things that people talk about when they talk about Agile, things like Scrum and so forth, in a way none of that really matters. 'Cause the important thing is that to be Agile, you have to get small increments into your user's hands as quickly as possible, then get feedback, then use that feedback to improve what you just wrote. And anything that does that as far as I'm concerned is an Agile process, whether it's got Scrum masters and PO's and all that other junk doesn't make that much difference to me. The important thing is that you're releasing code quickly and that you are changing what you're doing based on the feedback that you get from the code that you release. Now in order to keep that system coherent. In order to be able to have something valuable to release to your users, you have to use what's called, in Agile development, a story. So let's talk about stories for a moment. First of all, a story is a narrative. The word story is not some magic term that was invented by CS people. It's not some twisted definition that has a specific technical meaning. It's a story. The story should be a narrative then, and in order to be useful in the Agile world, it should be relatively short. A sentence or two. My general rule of thumb is that if a story can't fit on a Post-It note, it's too long. So short is important. What that story does, is it describes an end user performing some kind of domain-level activity. So it is describing your users at work. It is not describing your work, it's describing your user's work. And they're doing that in order to come up with an outcome which they find valuable. So a story then is a very technical thing in a sense, in that it is a story that is describing your users working in order to get a result that is a good result for them. Or to put it in another way, as I said a moment ago, stories describe your user's work, not yours. Now the point of that is that it provides value. In other words, if the story is defining something that your user does in order to get to a valuable place, then when you implement that story, you will have implemented a piece of code that does something useful to your end users, that gets them to a valuable place. So to sum up, Agile and DDD go very well together, particularly if you're implementing in terms of stories, which are themselves written in terms of the domain. So the next order of business is that we need to talk about how we would implement DDD, and that would bring us to the subject of microservices.