re: Domain Driven Design for Everyone Else VIEW POST

FULL DISCUSSION
 

Just wanted to chime in on the relationship between agile and DDD, as someone who's more acquainted with the former than the latter. Well, to be more precise, someone with a Scrum background.

I see no reason why these two methodologies need to be at odds with one another, based on this introductory article on DDD. The Scrum that I was taught by the Scrum Alliance has nothing to say about which work items should be prioritised (and so using the domain/core vs non-core dichotomy as a prioritising principle is fine) nor is it particularly interested in how you formulate your requirements (it is certainly opinionated towards user stories, but the common language developed by the DDD method could help you to write clearer user stories in a combined world).

So I think it's unfair to say the goals of the Scrum/Agile processes are an "illusion" and that achieving them is "wishful thinking". I believe they can be used in tandem with DDD and even achieve a level of symbiosis.

 

I'm going respond here with the clarification I put at the bottom of the article.

This is is a dig at capital A "Agile", the singular methodology that is sold by consultants as a fix all your development woes, as opposed to actual "agile", which is great, as it focuses on iterating on the problem of writing software, adapting to changes.

The two are not at odds to each other at all. "DDD" is a way to understand what you're doing from a business perspective, making sure that everything flows from it. "agile" is a way of building software so we always have something useful, adapting to change and new information, rather than following a plan or process rigidly. The two work incredibly well together.

"agile" accepts that software development is complex, in the same way that "DDD" accepts it. The problem is that "Agile", as it has been sold to companies, has been marketed as a process to "solve the problem" of software development. It pretends that software dev can be treated as a predictable process, in other words, as a complicated problem. That's the illusion I'm referring to. "agile" and "Agile" are two different things.

I'm a big fan of agile, I adhere to it's core philosophies. I'm just sad that so many company's have gotten it wrong and think it's just a bunch of processes you follow. It's become waterfall 2.0.

 

I'm a big fan of agile, I adhere to it's core philosophies. I'm just sad that so many company's have gotten it wrong and think it's just a bunch of processes you follow. It's become waterfall 2.0.

In order to prevent confusion for those new, I'd like to point out that there is a myriad of methodologies between waterfall and agile.

Nowadays, it is not a matter of choosing agile or falling into the waterfall.

code of conduct - report abuse