An Introduction to Domain Driven Design

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 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_graphic.001

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.

Round 1: True to PayrollHero’s style, my team decided to code for a machine that vends beer. We got down to writing all components involved in the machine: beer, a tray to hold the beer, a coin collection box, refrigeration involved (liquid nitrogen, of course), landing tray, the works. We then wrote down all the actions involved, inserting the coin, choosing a brand, waiting for the beer. Then we wrote down all possible scenarios: what if too many coins were inserted, what if the power ran out, what if the machine go stuck while vending the beer, what if the beer wasn’t cold, what if… and we went on and on.

Till Kiro came up to us and said our time was up.

We got no coding done. We barely opened a laptop screen. There was no product, just a bunch of ideas. Round one was an epic failure. We had a brief discussion on what to do. Kiro told us we needed to start small. Create a scenario, build a model, implement it and then go back to the drawing board to create another scenario.

Round 2: We needed a fresh perspective. We started from scratch, this time making sure that the developer in the room coded while we built the model. The process seemed slow but was far more efficient. Every non-developer would review the code to make sure everyone understood what was going on. When time was up we had our minimum viable product. By making our core domain small, we had a flexible model that we could work around. It was evident that Domain Driven Design helped us create our MVP within 45 minutes.

Timeboxing: The Bomb

In theory, DDD now seems like a simple idea. Even when you are modelling a vending machine, applying DDD to one problem is easy. What if you are dealing with 20 different problems at a time? Kiro showed us how multi-tasking can wreak havoc on a team. We were made to stand in a circle and pass around a “bomb” in alphabetical order. We were just getting good at it, when Kiro threw in another bomb that we were supposed to pass around in height order. A few seconds later another bomb was introduced that was to work its way around the group in order of birthdays. As you would imagine, we took ages figuring out how to pass three bombs around simultaneously. It was inefficient, messy and absolutely hilarious.

The idea of multi-tasking is just not sustainable. It wastes time and does not capture anyone’s complete focus. Timeboxing is far more effective. Getting work done one at a time allows you to apply DDD, keep everyone involved on the same task and thereby get everyone to focus their energies on a single plan.

Day 1 ended on a high note. Kiro threw ideas on modelling different problems at us and the developers enthusiastically practiced on them. The team was exhausted but an idea was borne out of a full day’s worth of training. We had big plans for the future, with new features in the pipeline.

Day 2 picked off from the previous day’s final tip – timeboxing. When you do tasks one at a time, it’s important to prioritize which feature from your backlog should be worked on. At PayrollHero, developers choose a bunch of issues and then vote on them. After ranking the issues, Kiro suggested we vet through what the problem really is before we go deeper into solving it.

Fact vs Opinion

Once you have identified a problem, it’s worth evaluating whether the problem is relevant or even real. Differentiating fact from opinion is another one of those obvious steps but everyone often misses out on it when you are deep into the process of solving a problem. It’s worth hitting the brakes and breaking down the problem and solution.

Problem Solution
Fact The problem should be based on solid data, maybe customer feedback or some other data analytics A solution that arises from analysing the facts of the problem. A quantifiable improvement is preferable
Opinion What the developers believe the problem is An opinion about the solution may be a source of new problems or ideas

Moving from the problem to a solution is what Kiro calls a Hero’s Journey. Using the facts of the problem, developers need to use their imagination to model the solution. The next step is to design the model and then implement the solution. Often the implementation brings up new problems and the cycle begins again. (If you were wondering, the name comes from the Star Wars protagonist, Luke Skywalker, who was faced with the problem of saving the galaxy, then he met Yoda, and finally used the Force to save Princess Leia and bring freedom and peace to the galaxy. Kiro is quite the sci/fi fan).

heros_journey_web_1024

This marked the end of the learning material that Kiro taught us. After this, we talked about models specific to PayrollHero and practised tackling them. An interesting exercise was to build a simple model, say a delivery system, and throw scenarios at it to see where the model breaks. The entire team enjoyed the brain teasers but more importantly, it helped us look at our product with fresh eyes and a different angle to approach our pipeline ideas.

The next few days are all about using DDD for some rigorous introspection and using the new learning as a foundation for future ideas. We also got the entire team to spend some time together with each other and our new interns. We went out for lunch, dinner and drinks. It was a great experience for both developers and non-technical members of the team. Overall, we learned that modeling can and should be used to make decisions, both for R&D and sales and marketing. It was not just about app development, it was a new way of thinking and building on ideas and executing them. While we are constantly improving our methods and changing our approach, we want the PayrollHero team to stay on their feet and continue being awesome consistently.


PayrollHero Team at Domain Driven Design Workshop Singapore

PayrollHero Singapore Payroll Team

Continue reading

Can We Be Lean In All Stages?

Payroll Hero sponsored the “Can We Be Lean In All Stages?” meetup in downtown Vancouver the other night by providing a few copies of The Lean Startup for their raffel.  If you have been reading this blog you know we purchased a few copies of Eric Ries’ The Lean Startup.  So, if you have an event in British Columbia that would benefit from having a few copies of the Lean Startup to give away then let us know more.  Take a moment to write a note on our Facebook page as to why your event would be a great fit.

Eric Ries, Author of The Lean Startup, Comes to Luxr

Today’s Luxr session was fantastic.  We had Eric Ries, the author of the best selling book The Lean Startup come by to have a fireside chat with us, moderated by Luxr co-founder Janice Fraser.  It was a great session with Janice asking some very relevant questions that allowed Eric to explain his thoughts on the lean startup world.  He told some great stories, including a funny one about his experience on Fox News.

Eric is a very sharp individual who has taken the tech community by storm with his lean startup concept and it was a pleasure meeting him again.  (Mike and I met up with Eric a while back in Whistler, which indirectly lead us to Luxr and moving to San Francisco)  As part of our bulk purchase of Eric’s book, we get 4 hours with him to chat about whatever we want.  I look forward to having him over to the PayrollHero house and showing him in more detail what we are up to.  Sounds like mid December we will have that opportunity.

Here are a few pictures from today:

(L – R) Piotr Banasik, Stephen Jagger, Eric Ries, Michael Stephenson, Adam Baechler

Eric Ries signing 1 of our 500 copies of The Lean Startup (watch this blog for book giveaway details)

Janice Fraser of Luxr and Eric Ries

(50 Coffees)

500 Copies of The Lean Startup By Eric Ries

When Eric Ries new book, The Lean Startup, was about the be launched, he put up 3 unique packages online.  All were bulk book deals with some “extras” added in.  We bought the single “Luxr Bonus Package” which included 500 copies of The Lean Startup, entrance to the Luxr program, 4 hours with Eric Ries and much much more.  This purchase triggered our move to San Francisco, the return of some of our team from Manila and a laser focus on getting PayrollHero launched in North America by year end.

If you want a copy of The Lean Startup, drop your email address in here, we will be selecting a few and sending them free copies of the book in the coming weeks.

Here is what 500 copies looks like packed into a car: