Here comes another post in "remarks from awesome DDD Europe 2016" series. If you find it boring or not really revealing, I'm the one to be blamed - some ideas, especially related to modelling & design are truly hard to convey.
Many software developers are really hooked up by DDD - pretty much everyone I know who's enthusiastic about DDD is a software developer, and believe me - I know many analysts, product owners, SMEs, etc. - people who play various roles, are responsible for different area within a process of creating IT products. But no-one but developers truly cares about DDD, which may be quite odd at the first glance:
- Isn't DDD technology-agnostic?
- Are devs the only ones who are interested in creating a model?
- What kind of technical knowledge is required to start practising DDD?
Answers are obvious, so I'll skip them. Until now, my way of thinking about that was quite simple:
- devs are the ones who care about DDD, because they are they know development process (& design in particular) best, so they are the only ones who realize how important it is to discover the proper model
- you don't have to be a kick-ass dev to master DDD; open mind, good will & some smarts are required to get you rolling & it's really up to you whether you can get decent in it (DDDing, I mean)
So, in other words - business analyst or a fresh out-of-college junior dev may shine in DDD, when given the opportunity.
But one of the DDD Europe 2016 speakers (I think it was Eric Evans, but I'm not 100% sure) said something opposite & this has made me thinking (this won't be a verbatim quote, just a paraphrase - I do not remember the exact words):
To do DDD in a proper manner, you need to embrace technical mastery first. People who don't meet this requirement will waste too much time & effort on struggling with the way how to implement the model, instead on spending this time on actual modelling.
Audience has picked it up immediately - actually it's hard to disagree if you think about that for a minute:
- there's an infinite number of models you can create for a given domain ...
- ... & models are driven by the context you're interested in ...
- ... but as models have to be common (including Ubiquitous Language) for both business & code (that forces you to consider language & platform specifics as well) - these both factor groups drive the exact shape of the result model
So, the model is a product of a joint work of two groups of experts (with an emphasis on the final word):
- domain experts
- technology (implementation) experts
Capable devs will have a lot of trouble with creating a great model when paired with people who don't really know the domain (due to whatever reason), but THE SAME (or rather - similar) trouble will happen if true domain experts are to co-operate with devs who don't know their drill well (because they are inexperienced or just ... well, not that capable ...).
Domain model that reflects the domain specifics & supports the valuable scenarios but isn't really implementable (or has serious constraints in terms of implementation / architecture) is a prelude to something very nasty that isn't likely to end well ...
Pic: © PointImages - Fotolia.com
