BT

Paul Rayner Says DDD and Agile Can Coexist

| by Matt Fletcher Follow 0 Followers on Jun 20, 2016. Estimated reading time: 2 minutes |

In his talk at Domain Driven Design Europe 2016, Paul Rayner made the case for incorporating domain-driven design (DDD) into the agile software delivery process.  He views agile as a way of organizing work, not as prescribing how to do the work.  He believes agile practitioners often don't pay enough attention to design, and promotes DDD concepts as a way of addressing these failings.  Going further, Rayner believes that combining agile with DDD can accelerate product delivery.

In Rayner's experience as a consultant, he has seen many teams doing agile who stress the importance of MVP (minimum viable product) to the detriment of design.  He quoted Douglas Martin on the inevitability of design: "The alternative to good design is bad design, not no design at all."  In trying to avoid waterfall's "big design up front" and do the minimal work needed, these teams end up with bad design.  The Agile Manifesto actually says "Continuous attention to technical excellence and good design enhances agility".  The purpose of agile is not speed and only speed, but agility.  Agility can be achieved through good design.  It is in fact the purpose of design according to another quote Rayner offered up from Venkat Subramaniam: "A good design is not the one that correctly predicts the future, it's one that makes adapting to the future affordable."

He pointed out that design is fundamentally iterative, and as such, can be incorporated easily into agile.  Design is a process of discovering what you don't know and expressing complex ideas simply.  Since you never know all the facts up front, your design will necessarily change over time.  Taking the time to do the discovery, and to express new knowledge in the delivered code will pay dividends in time saved later, as the code itself will be more agile.  One method for doing this is the whirlpool process of model exploration, in which you iterate between challenging your existing model of the domain with a new scenario, proposing a new model, and writing the code to implement it.

Rayner also listed other ways agile teams he has worked with often fail from a DDD perspective.  One is viewing continuous refactoring to a good design as good enough.  This may clean up the code, but DDD emphasizes introducing new concepts.  These new concepts are not emergent from the code, and therefore cannot be created solely through refactoring, but rather are concepts modeled from the business.  Which adds business value, whereas refactoring, by definition, does not change the functionality of the software.

Having a defined "product owner" role in Scrum can easily cause others on the team to view that person as the sole conduit for all business needs/knowledge, noted Rayner.  DDD advocates that everyone know the domain.  This is where the complexity lies, not in the technical aspects of the problem.  So in order to achieve a good design, thereby increasing agility and business value, everyone on the delivery team needs to know the domain.

Rate this Article

Adoption Stage
Style

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Domain Driven Design comes from the Agile community... or at least the XP one by Jason Yip

Eric Evans was / is part of the Extreme Programming community and Domain Driven Design was referenced by most XP people (which I believe was still the dominant Agile method at the time?) when that book first came out (2003). The DDD Ubiquitous Language was mentioned as a better alternative to the XP practice of System Metaphor.

YAGNI by Steven Gordon

Creating code structures not needed by any particular user story just because they represent an entity or relationship in the domain model is wasteful - YAGNI.

If the code structure should be created, there should be at least one user story that utilizes the domain entities and relationships. And then do not create the code until an applicable user story is being implemented.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

2 Discuss
BT