A Matter Of Perception And Concept

A Personal Experience

Last weekend was a hectic one. I had many things planned for both Saturday and Sunday. Saturday, everything went according to plan. Sunday not so much. After arriving, on time, for my hair appointment, I was sat down (with my glass of water and 3 Lindt chocolates) to discuss the details with my designated stylist. Soon we both realised we have a problem. When I made the appointment, I asked for a "half head highlights", which turned out to be just a 30min appointment. What I really wanted was in fact a "pre-lighten regrowth and t-section", which needs a slot of at least 2 hours. The only acceptable solution was to reschedule for later the day. The impact of using the wrong terminology in this situation was a personal fiasco as my whole day's plans went out the window.

It made me realise once again the importance of communication and the use of a common language within a specific domain. As software developers, we work across various markets and domains and for every new project, we need to familiarise ourselves with the domain concepts to ensure the conceptual integrity of the applications we develop.

That same day, at the hairdresser's, I decided to write this blog, focusing on how context can change perceived understanding between different people.

As it happens, I had recently experienced a personal change in perspective, related to blogging in general.
- So, this is my first blog. Ever. -

We live in a time of information overload. We are drowning in the abundance of opinions and regurgitations. Until now, my inner-critic prevented me from joining the masses of me-isms and self-promotion. Too much information is a problem in itself. This is one way of looking at it.

Another - I've come to ponder the possibility that this perception may perhaps just be an excuse, a cop-out. I read somewhere recently "You are one in seven billion; your progress is not meant for you alone." So, I started going down a different train of thought. Why not embrace the opportunities of the digital era? Share a bit about me, my perceptions and my personal experiences. Consider that there are seven billion different perspectives on the human experience. It's an extraordinary thought!

Domain Driven Design

Back to my topic of context, I want to share my appreciation for Domain Driven Design, with my focus mainly on the value of establishing and using an "ubiquitous language". This supports a significant part of DDD's strategic design and the "Bounded Context" pattern.

It's addressing an age old problem of communicating concepts and ensuring a shared understanding of it. I've often wondered secretly by myself after walking out of a meeting room if everyone leaving the door have the exact same understanding of what exactly has been agreed upon. What are the odds?

My favourite example is the abbreviation CBT. Someone from an educational domain may think "Computer Based Training"; another from Human Psychology domain may think "Cognitive Behavioural Therapy"; and on the odd chance there was a person with a certain fetish in the audience, well, that would be quite another ball game all together!

Many project teams in the past had to learn from their mistakes the hard way. As the saying goes, rather learn from other's mistakes than your own. It's less painful that way.

Context

Definition The setting in which a word or statement appears that determines its meaning. Statements about a model can only be understood in a context.

Bounded Context

Definition A description of a boundary (typically a subsystem, or the work of a particular team) within which a particular model is defined and applicable.

As with the CBT example, the term can only be understood correctly, within context, once the boundary has been defined explicitly.

All players in the project team will then be bound to this context to:
1. specify business requirements
2. design the domain model
3. name your code

Ubiquitous Language

Definition A language structured around the domain model and used by all team members within a bounded context to connect all the activities of the team with the software.

Once the bounded context has been defined, all collaboration and communication should be committed to using this language. This is where the real benefit lies, as people will develop a shared view of the concepts.
And voilà! No more misunderstandings.

Final Words

Domain Driven Design serves as guide with principles, patterns and philosophies. My purpose here was to raise awareness. At this point I'll hand you over to the experts. For further reading, my personal favourites are Eric Evans, Vaughn Vernon and Scott Millett.