I've been talking a lot about Domain Driven Design (DDD) lately, be it at meetups or with clients, so I thought I'd write down my thoughts and see ...
For further actions, you may consider blocking this person and/or reporting abuse
When I started trying to do DDD, I was focused on technical patterns like Repository, Domain Event, etc. Much like "Agile" shops think if they get the processes right, the software will automatically be good; I thought if I used the right patterns, the software would be good. Both of which turn out be patently false.
Your article tells me what I wish I had known about DDD from the start... that it is not about technical patterns (and in fact, I don't believe I use any of them from the book today). It is all about learning the "domain". That's the key to writing good software.
Thank you!
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.
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.
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.
thanks for the post, I can agree.
Most of the time the domain experts are also very motivated in working with you to develop the best possible software in the given time, that makes this job even better!
Well said!
Wonderful thoughts here! I think that I would invert your definitions of complex and complicated however. This makes it easy to think of complex (many-folded) problems being broken down into simple (from simplex; one-fold) problems. The fact that a complex problem sits in a human context takes it to the realm of complicated, which would mean exactly how you've defined "complex."
Love the focus on communication and shared understandings. :)
Wow, great post!
Thanks Ben!
Very well said!
Some nice insights here!