Role of technical excellence in DDD?

Role of technical excellence in DDD?

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 -

Sebastian Gebski

About Sebastian Gebski

Geek, agilista, blogger, codefella, serial reader. In the daylight - I lead software delivery. #lean #dotnet #webdev #elixir. I speak here for myself only.