... about connascence and DDD

At the last DDD Europe conference, a lot of attention was given to "connascence". Especially in a workshop of the ever great Paul Rayner that was all about the term. 

I hadn't heard of it yet (<shame>), but it turns out it's the same as what I always called "coupling". While "coupling" is the degree of dependencies between modules, "connascence" focuses on the need to change one component if another changes.

Now, there's 9 different kinds of connascence and they're all listed on wikipedia. However, for me, there's also a link to why we like Domain Driven Design.


The whole idea of DDD is to design software by capturing the language of the business and keeping all business rules in the domain model. At the same time we avoid application logic to sneak in the domain model or business logic to sneak out of the domain.

The reason why we do all this effort is that we want to be connascent to the business domain. When the business changes, we want our model to change as well. If they're not connascent, it means that we modelled the wrong thing.

We don't want our domain model to be connascent to the requirements gathered in a document by a functional analyst and handed over to us.

We don't want our domain model to be connascent to a list of features added to a backlog by a product owner in a scrum process. 

We definitely don't want our domain model to be connascent to a UI mockup. 

The UI changes all the time. Requirements change all the time. Product owners change their mind constantly. Instead, business rules don't change that often and when they do, we want to change our domain model with it.

Greetings
Jan