Why It’s Hard To Learn About Domain-Driven Design (or any other kind of design, for that matter)

I’ve recently been revisiting the books I read on Domain Driven Design a few years back when I was just getting my feet wet with the literature in that area. (These two are my favorites so far.)

In the first couple of chapters of the canonical DDD book, Eric Evans opines that developers are often very happy to tinker with a new technology, a new design pattern, or a new process, but they are usually unwilling to invest effort into the actual business of modelling the core concepts of the problem domain itself.

He continues by talking about how projects where even a few of the developers were not invested in this process meant that the effort was largely wasted, and that productivity stayed more or less constant despite the enormous effort poured into the modeling process by the rest of the folks there.

This isn’t particularly surprising to me; there are a variety of reasons I can see as to why your average developer would be more excited about adopting a new library to make cloud deployments easier, or adding a new code review process or the like to their dev teams repertoire of practices:

  • There exists a lot of documentation and material that one can learn independently from.
  • The effects are seen pretty much immediately (whether for good or for bad).
  • Credit from the organization can generally be traced to the originator of
    the practice
  • It’s a unit of work that can be done on e.g. lunch breaks, spare time, on
    the transit ride home, etc.

Building a rich domain model, on the other hand, bears very few of these favorable characteristics. Why not?

  • Practicing it independently is not all that helpful, as a domain model is
    only provably robust when a variety of developers and domain experts can use it
    to improve communication and productivity in the team.
  • You rarely see the payoff until the middle-to-late stages of the project,
    and it does generally slow things down at the beginning.
  • Because buy-in from the team is required to make it effective, there is
    rarely going to be a single person who is going to get the credit for the
    initiative, and so the risk/reward is diluted across the team.
  • It takes long, concerted bouts of practice to get good at it (preferably in
    the presence of people who have done it well before.)

As I was thinking about this in the context of Evans’ book, I realized that these difficulties prevent experience reports on DDD from being communicated effectively in the developer community at large. In addition to my involvement in PyCon Canada, I have also been involved in a variety of meetup groups in Toronto, San Francisco, and Vancouver that are focused on code quality and best practices (e.g. Code Retreat, Agile/XP groups, clean coding groups, etc.) And yet, I don’t think I’ve ever heard a talk on how a team switched from Approach X to development into a tight focus on creating a rich domain model, and what the subsequent consequences were.

Again, one can imagine a variety of reasons as to why this would be the case.

  • There are probably relatively few developers who have even had this experience before. (Evans was possibly the first to write a book on it, and even he only had 3-4 examples to show off in the first few chapters. Half of them were failures.)
  • Some prior experience with the domain itself is required to benefit from the discussion, which necessitates a significant introductory component (which has the potential to be boring.)
  • Since the benefit of DDD is generally seen in the long run, the speaker would have to condense an enormous window of experience into a single talk.
  • The amount of work it would take to address the topic properly (choosing the appropriate level of depth for each part of the discussion) is daunting.
  • Many people with real-world experience in this space are prevented from talking about it due to NDAs, etc.

Nonetheless, this is the sort of talk that I would love to see attempted more
often at any general technical conference. The closest that I think we get are
focused refactoring sessions like this recent (awesome-sounding) talk from RubyConf AU.

I am going to play with creating some ‘artificial’ DDD scenarios that are in problem domains that are more likely to be familiar to developers, much like Vaughn Vernon did in his recent book.

In the interim, if anyone out there has seen an effective talk or presentation on a project that used (or better yet, was refactored to focus on) a rich domain model, I would love to see it!

6 thoughts on “Why It’s Hard To Learn About Domain-Driven Design (or any other kind of design, for that matter)

Leave a Reply to Ameozeher Cancel reply

Your email address will not be published. Required fields are marked *


You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>