Sebastian Gebski

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:

  1. Isn't DDD technology-agnostic?
  2. Are devs the only ones who are interested in creating a model?
  3. 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):

  1. domain experts
  2. 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 -