DDD-Domain Driven Design or Deadline Driven Design?

DZone 's Guide to

DDD-Domain Driven Design or Deadline Driven Design?

When I asked who experienced Deadline Driven Design, almost all would laugh and feel connected — find out more about DDD!

· DevOps Zone ·
Free Resource

When I asked my clients who know Domain-Driven Design, less than 10% would nod their heads.

However, when I asked who experienced Deadline Driven Design, almost all would laugh and feel connected.

Put the Cart Before the Horse

Let me share an experience once I delivered DDD methodology to a customer.

BA(Business Analysis) Mr. T is the one I coached for adopting event storming and DDD methodology to analyze the requirement and do the design afterward in Lab1. After a short break, we met again for a second project Lab2.“

We were standing in front of the following map which was completed by BA Mr. T. He looked quite puzzled with what he did.

sticky notes
 User Stories Map Without Event Storming

I said: “So this is the user story you sorted out? But where is the event storming”.

Mr. T turned down a little bit his tone and avoided my eye contact as well, and said: “In Lab1, it seems to me that the output of event storming is just the user stories. So I thought it might be useful to come up with the user stories directly, so we can start the sprint more quickly. ”

cart before the horse
Put the cart before the horse
With a few seconds of silence and a little help of fresh air. I said that: “I agreed, a user story is one of the visible outputs of event storming, However, it’s much more than that, and more importantly how do you know the user story is correctly reflecting the system’s mind.

Then I started a short lecture of values of event storming.

“First of all, we need to involve developers interactively. Event storming is a bridge connecting domain expertise and the developer’s mind. With such an effective connection, the software can be built from domain expertise’s mind flow into developer’s mind flow and go into the computer via the developer’s hand.”

“Second, we need to identify different domains of our system, so we can prioritize them strategically. (eg separate them as microservices or modules, or import 3rd party system to support.)”

“You also want to understand the Aggregate output so that we can design the mindset of each unit of the system.”

Mr. T smiled sneakily and said, “I am OK with what you said, but we need the agreement of PO”. (PO is product owner)

After a replay the above conversation with PO who is the real boss to push the deadline.

The words I added to the PO is that “I understand we need to meet the deadline. However, sharpening the knife doesn’t delay chopping wood. Event Storming is invented to do business process analysis in fast-paced.”

With one day intensive activities, developers, BA, and the coach finally got the parts of the process’s event storming to look like this.

Part of the Event Storming map

Part of the Event Storming map

Standing in front of this wall, I saw Mr. T relieved.

I asked, “What’s the difference regarding the user stories before and after?”

Mr. T said: “Firstly, we identified a lot of hidden user stories. eg: ’Contract Body Attachment‘ Aggregate’, this was missed when I tried to sort out all the scenarios in my head.“

I said: “Why did you miss that bit, it seems quite important.”

Mr. T said: “Yep, Strange! When I want to grasp all the user stories from my mind, it seems like I only see the forest, but I can’t see the woods. So I can’t identify a lot of details. But when we start event storming, I feel like I step into each path of the forest and go through it, the important objects are getting clear.”

I said: “Right, event storming helps you expand your mind into these unlimited walls and make them visible to everyone. It does not only help you create clearance on the business process but also help all the developers to see all the details and understand the mindset of the whole process.”

I added: “What about the communication. Is that helpful?”

Mr. T nodded his head, and said: “Yep, it solves some of my puzzles in the beginning, I know what slows me down me, and then I picked up the phone and asked the end-user in detail and that’s helpful.”

I said: “You also received tons of questions from the developer team, right? They won’t be able to ask those questions until they see all the details you spread them into the wall. If they don’t ask you those questions in advance, they would ask you in the late time of the sprint. Otherwise, they are likely to stuck or hide the problem and you would see huge numbers of WIP items in your kanban. That’s a common pitfall when using scrum kanban, Too many WIP. But we need to ask why shouldn’t we?”

Mr. T smiled and he seemed quite familiar with the scenario that I described.

“Now you know how many domains we should separate, which domain we should work on in sprint 1 instead of putting a lot of scattered user stories into one sprint, right?

We even figured out how many microservices we are going to have for the system and how they are going to interact, isn’t it helpful?”

Sharpen the Knife Doesn’t Delay Chopping Wood

Let’s end our story here, Event storming is a simple but powerful tool to hold the two-person job conversation.

So what is the two-person job? Let me expand it in my next blog. I am going to describe how event storming saves the software design domain.

ddd, deadline, devops, domain driven design, user stories

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}