I’m participating in nuggets Creators Camp # 4, click here to learn more and learn together!

The answer

Let’s start with the answer: DDD definitely applies to Scrum development. Now let’s see, why is this question? How did the conclusion come about?

What is the DDD

The concept of DDD (Domain-Driven Design) was developed in 2003 by Eric Evans in domain-Driven Design: Those interested in this book are referred to my reading notes in Dzjcomplexities in the Heart of Software and are advised to buy the original version. If I could sum up the book in two sentences, it would be:

  1. Software complexity comes primarily from domain complexity
  2. Model-based design can help solve domain complexity problems

The book introduces many methods of domain modeling, which can be divided into tactical design and strategic design. The tactical design mainly introduces the basic building blocks of the model, such as ENTITY, VALUE OBJECT, AGGREGATE, REPOSITORY and so on. Strategic design mainly introduces how to deal with the relationship between models and models, including BOUNDED CONTEXT, CONTEXT MAP and other patterns.

What is the Scrum

Scrum is an agile development framework that defines a set of skeleton activities for iterative development and the roles involved in those activities. The main roles in Scrum include:

  1. The Scrum Master is the Scrum coach and team leader who ensures that the team runs Scrum properly and helps remove obstacles in the implementation.
  2. Product owner, define product direction and vision, define product release content, priorities and delivery time, and be responsible for product ROI;
  3. The development team, a small cross-functional team of 5 to 9 people, has the skills needed to deliver usable software.

The main activities revolve around sprints and include:

  1. Sprint Planning: A Planning meeting where the team decides how much Product Backlog can be completed in the next iteration
  2. Daily Scrum: Daily stand-up meetings where team members take turns answering the following questions:
    • What work did you finish yesterday?
    • What are you going to do today?
    • Are there barriers to achieving your goals?
  3. Sprint Review: Review meeting
  4. Sprint Retrospective: Retrospectives are made at the end of the Sprint for continuous process improvement

The following diagram visually illustrates the main flow of activities and the roles involved in Scrum.

Why the question

The word Scrum comes from the game of rugby, in which two teams of players gather together in a Scrum for the ball. There are many similarities between a scrum-based development team and a Rugby team. For example, players in a Rugby team are divided into three functions: offensive, defensive and special team. The three have their own advantages and cooperate with each other. In a Scrum team, there are only three roles: Product Owner (PO), Scrum Master, and development team, where the development team members are highly compatible and interchangeable. In addition, rugby is a game with short time, no protective gear and flexible running. Accordingly, Scrum development is characterized by short iteration cycle and flexible incremental planning, which is very suitable for rugby.

Scrum focuses on the collaboration between agile development team members and how the team works. DDD’s focus on the business -> model -> code design process is reminiscent of the requirements -> software -> coding of the waterfall development process, and this way of working does not match Scrum’s emphasis on agile development. If this is taken at face value, it is easy to ask: Is DDD appropriate for Scrum development?

Model exploration vortex

Eric, the author of DD, has already answered this question. He has a metaphor for how to build models in an Agile environment: Models explore the vortex!

So how do you explore the vortex based on such a model for agile development? Next, we will use EventStorming and Example Mapping to illustrate this.

Harvest & Document

We begin our model exploration by harvesting and recording the current state. The main goal: gather reference scenarios, capture snippets of the model, and then leave most of the ideas behind. EventStorming can be a starting point for this phase. EventStorming is one of my favorite tools that helps you gain a lot of business knowledge in just a few hours when you collaborate on complex business scenarios. To be successful at this stage, the right domain experts must be involved.

Workshop

In order to conduct the Workshop, you need to find enough space (such as a room with a wall 8 meters long), and you need a whiteboard. Now we can start capturing the current state via EventStorm. We gave participants an orange sticker and a marker. We asked them to write down domain events (a pattern that Eric later added to the reference book). In short, a domain event is something that happens in a domain that is business-related. We want to capture the current state of domain events and post them on the wall in chronological order.

Tell a story

When each domain expert has written down their domain events, a story can be told. Ask participants to tell stories to confirm the timeline and remove duplicate events. People usually have different opinions on domain knowledge when judging whether a domain event is the same or different. Mark hot spots with bright colored stickers.

Make the implicit explicit

The core of EventStorming is that we only talk about explicit and visible things. There is so much knowledge we can capture in domain events and hot spots; We can capture more types of knowledge in other colors. The standard EventStorming color is:

  • Blue: Action/command
  • Pink :(external) system
  • Purple: policy/actual business constraints
  • Green: Information

The basic process would look something like this, and the key point here is that everyone in the room agrees. If we don’t know where to start, try to follow this process. Remember to make the implicit explicit.

Bias blind spot

Now that the story is complete, we want to introduce sample mappings. For the most part, people would now consider it a waste to introduce another tool. The story has been visualized, but have we got the full story? The problem is that everyone is affected by cognitive bias, especially when we encounter information overload.

We notice things that are ingrained in our memory or that are often repeated; This is called the background effect and attention bias. We are also drawn to details that confirm our existing beliefs; This is called the observer effect. Especially the bias blind spot, in the process of exploring the field, we are more likely to notice the defects of others, while ignoring our own defects.

To combat these biases, we need to use different perspectives and tools. Example mapping helps because it focuses more on concrete examples. Brainstorm examples on green stickers. Put yourself in the other’s shoes and see how these examples affect current EventStorm. If it’s a blank space in the current system, mark it with a hotspot to make it unambiguous! Now the people in the room should have a good sense of what’s going on. We can already see the presence of bounded contexts, or see which parts are entangled with each other without clear boundaries.

SCENARIO

Now that we have knowledge of the current state of the system, we need to do the same for what we are going to develop next. We can create a new modeling space and do EventStorming again.

Rehearse and refocus on the difficult parts

Once we have all the events, all we need to do is rehearse the events as we did last time, enforce the timeline and remove duplicate domain events. The other thing is to refocus on the hard parts and find the complexity. We use yellow labels to indicate consistent business rules that always precede a domain event.

We look for consistent and ultimately consistent business rules first (yellow and purple) and focus on those parts. Keep the story consistent by adding stickers of other colors. Focus on the language used; The ambiguous words must be found. Also, start adding actors to make it clear who is responsible for which parts of the story. All of this information, taken together, is all you need to define a bounded context.

The example map

Use the example map again. Start with brainstorming and write examples next to EventStorm. Only this time we will take the sample map a step further by structuring the sample as vertical columns using business rules. Write the business rules on the blue sticker above the example. It is important that there is only one business rule per column. Having only one business rule means that a particular example can occur multiple times under different business rules.

The business rules will match the business rules on your EventStorm, where you may also find new business rules. The goal of both tools is to share knowledge and explore complex business domains, so don’t spend too much effort trying to make them perfectly aligned.

MODEL and CODE PROBE

With the new knowledge we need, it’s time to start modeling. We’ll start by exploring the different models to see how they behave in the example on EventStorm and your example mapping. Try to find at least three models and iterate through them quickly. Once you finally have a working model, we can now break down our sample mapping, discuss which business rules are most important, and formalize the sample.

With a working model and formal examples, we can now start coding. Because we know what the system needs to do, it’s easy to use test-driven development to write code prototypes of the model based on formal examples. So we can constantly refine our language and challenge our models.

conclusion

This paper addresses whether DDD is suitable for Scrum development and combines EventStorming with ExampleMapping to explore the domain model in an iterative manner suitable for agile development.

Refer to the link

  • scrumprimer.org/anime
  • www.domainlanguage.com/ddd/whirlpo…