What is domain driven design?

Twice a year we gather the whole PayrollHero team to a single location for learning, retrospectives, bonding, and adventure. This time, we brought Kiro Harada into Singapore from Japan to do a 2 day workshop as part of our all hands meeting. One of our interns captured the sessions so that we could share some of our learning with the startup community.

Introducing Pragya Gupta, Business Development Intern at the PayrollHero Singapore office. She will be contributing to the PayrollHero blog from time to time and wrote the following post. With Tech in Asia’s permission we reposted it here. 

The PayrollHero offices are buzzing with new energy. This week, the entire team flew in from Manila and Whistler to Singapore and worked through two days of intense training on Domain Driven Design with Kiro Harada. After the rigorous learning retreat, the team emerged with renewed perspective and restless enthusiasm. In an endeavour to contribute to our community, we want to share with you what Kiro taught us.

The learning retreat was conducted by lean and kaizen expert Mr. Kiro Harada. Kiro flew in from Japan and spent time with us both as part of the workshop and just to guide us after it.

Domain Driven Design is all about communication. The gap between what developers want to create and what stakeholders in the company understand can be massive, potentially detrimental to the company. Even between developers, it is hard to maintain a common language as domains grow larger. This makes it tougher to model a problem which leads to further miscommunication.

Blind men and the elephant

For you and me, miscommunication sounds like an obvious problem. But what does it mean in a tech company for people who are not familiar with domains and modelling? To give us an idea of what he meant, Kiro told us about the 5 Blind Men and the Elephant. Each blind man gets a part of the elephant: like the leg, the trunk or the tail. Individually, the blind men know everything about their allotted parts. But when they regroup, one man calls his part a tree, the other man calls his part a snake, and so on.

Different perspectives colour reality and computer programmes cannot distinguish between the two. So what can you do to ensure that everyone is on the same page? The solution to the Blind Men and the Elephant problem is for each blind man to observe his part, regroup, model (or draw) what they observed, go back, make observations and repeat the process till they finally put it all together. You collect information and switch positions to ensure that everyone’s perspectives are clearly understood. The idea is to move from a state of –

Not knowing what you don’t know (or alternatively, knowing what you know)

to

Knowing what you don’t know

DDD is intended to take you back to the drawing board, where you design incrementally. The model must constantly evolve – from building a scenario that describes a model which is written into code that creates new scenarios, and the loop regenerates itself. Exploring models with creative collaboration while consciously focusing on the core domain is what DDD helps you do.

DDD in Practice: Modelling a Vending Machine

The concept of DDD can be vague unless you put it into action. Kiro chose to do just that by splitting us into teams and giving us a problem to model. The only instructions were to code for a vending machine.