Reaching a Shared Understanding through a Shared Language

An output of knowledge crunching and an artifact of the shared understanding is a common Ubiquitous Language (UL). When modeling with stakeholders and subject matter experts everyone should make a conscious effort to consistently apply a shared language rich in domain-specific terminology. This language must be made explicit and be used when describing the domain model and problem domain. The language should also be used in the code implementation of the model, with the same terms and concepts used as class names, properties, and method names. It is the language that enables both the business and development teams to have meaningful communication about the software. You will learn more about the UL in Chapter 4, “Model-Driven Design.”

UL is used to bind the code representation of the model to the conceptual model communicated in language and diagrams, which the business can understand. The UL will contain terminology from the business as well as new concepts and terms discovered when modeling the use case of the problem domain. The shared understanding that a UL prevents the need to constantly translate from a technical model to a business model, thus removing the chance of vital insight being lost.

The Importance of Domain Knowledge

Domain knowledge is key, even more so than technical know-how. Teams working in a business with complex processes and logic need to immerse themselves in the problem domain and, like a sponge, absorb all the relevant domain knowledge. This insight will enable teams to focus on the salient points and create a model at the heart of their application’s code base that can fulfill the business use cases and keep doing so over the lifetime of the application.

If you can’t speak to your business users in simple terms about complex concepts in the problem domain, you are not ready to start developing software within it. To constantly deliver updates at a rapid pace on the complex applications you are building, even as the whimsical business keeps chopping and changing features, you need to refocus your efforts during design and development—you need to focus your team on the business’s problems and not just technologies.

The Role of Business Analysts

It may seem that the role of the traditional business analyst is no longer required in the world of DDD; however, this is not the case. A business analyst can still help stakeholders flesh out their initial ideas and capture inputs and outputs of the product. If you have odd whiz-kid developers and are nervous about putting them in front of domain experts, you can also use business analysts as facilitators to help communication. What you don’t want to do is remove the direct communication between the development team and the people who understand that part of the business the most.

An Ongoing Process

Knowledge crunching is an ongoing process; teams should continually be working toward a simple view of the problem domain that focuses only on the relevant pieces to aid the creation of a useful model. As you will learn in Chapter 4, model-driven design and the evolution of a domain model is an ongoing process. Many models must be rejected in order to ensure you have a useful model for the current use cases of a system. Collaboration between the development team, business stakeholders, and subject matter experts should not be constrained to the start of a project. Knowledge crunching should be an ongoing concern with the business engaged throughout the lifetime of the application build.

It is important to realize also that with each iteration of the system the model will evolve. It will change as and when new requirements are added. New behaviors and use cases will require changes to the model therefore it is important for the technical team and the business experts to understand that the model is never done; it is only useful for the problems at hand.

As each iteration passes the team’s understanding of the problem domain improves. This leads to deeper insight and design breakthroughs that can vastly simplify a model. When the system is in use the model may also need to evolve due to technical reasons such as performance or better understanding of the systems usage. A good model is one that is supple to change; a mature model holds rich and expressive concepts and terminology of the problem domain and is understood by both the business and technical teams.

Domain Experts vs Stakeholders

A problem space gives you a set of requirements, inputs, and expected outputs—this is usually provided from your stakeholders. A solution space contains a model that can meet the needs of the requirements—this is where domain experts can help.

As shown in Figure 2.2 if your stakeholder is not a domain expert then his role will differ greatly from that of a domain expert. A stakeholder will tell you what they want the system to do; they will focus on the inputs and outputs. A domain expert on the other hand will work with you in order to produce a useful model that can satisfy the needs of a stakeholder and the behaviors of the application.

Deeper Understanding for the Business

Working with a domain expert will not only enable development teams to gain knowledge about the problem domain that they are working in but also help the domain expert to qualify her understanding of the domain. Concepts that may have been implicitly understood by the business are explicitly defined by the development team and domain expert, which leads to improved communication within the business itself.

Engaging with Your Domain Experts

To enable a high level of collaboration, it is recommended that you collocate the development team with domain experts who will be on hand to answer questions and participate during analysis at impromptu corridor or break room meetings; that’s something that is lost when the communication is restricted to weekly project meetings. Collaboration is such an essential part of DDD; without it, a lot of the design breakthroughs would not happen. It is this deeper design insight that makes the software useful and able to adapt when the business processes change.

If it’s not possible to sit with your domain expert, join her for lunch. Spend as much time as you can with her, and learn as much as possible. If you thrive on delivering high-quality software for personal satisfaction or career goals, then eat, sleep, and breathe the domain—you will be immensely rewarded

Focus on the Most Interesting Conversations

Don’t bore domain experts and business stakeholders by going through a list of requirements with them one item at a time. As stated before, a domain expert’s time is precious. Start with the areas of the problem domain that keep the business up at night—the areas that will make a difference to the business and that are core for the application to be a success. For example, asking the domain experts which parts of the current system are hard to use, or which manual processes stop them from doing more creative, value-adding work. Or what changes would increase revenue or improve operational efficiencies and save money from the bottom line. It’s often a good idea to follow the money and look for the areas that are costing the business money or preventing them from increasing revenue. The most interesting conversations will reveal where you should spend most of your effort on creating a shared understanding and a shared language.

Start from the Use Cases

The best place to start when trying to understand a new domain is by mapping out use cases. A use case lists the steps required to achieve a goal, including the interactions between users and systems. Work with business users to understand what users do with the current system, be it a paper-based process or one that’s computerized. Be careful to listen for domain terminology, because this forms the start of your shared language for describing and communicating the problem domain. It’s also useful to read back the use case to the domain expert in your own understanding, so they can validate that you do understand the use case as they do. Remember: capture a process map of reality, understand the work flow as it is, and don’t try to jump to a solution too quickly before you truly understand and appreciate the problem.

Ask Powerful Questions

What does good look like? What is the success criteria of this product? What will make it a worthwhile endeavor? What is the business trying to achieve? The questions you ask during knowledge-crunching sessions will go a long way toward your understanding of the importance of the product you are building and the intent behind it.

Here are some examples to get your domain expert talking and revealing some deeper insight into the domain:

• Where does the need of this system come from?
• How will this system give value to the business?
• What would happen if this system wasn’t built?

Sketching

People often learn quicker by seeing visual representations of the concepts they are discussing. Sketching simple diagrams is a common visualization technique DDD practitioners use to enhance knowledge-crunching sessions and maximize their time with domain experts.

You can start by drawing sketches on the whiteboard or on paper. If you keep them quick and informal you can quickly iterate on them as the conversation progresses.

Unfortunately, many developers find it difficult to create effective diagrams. However, when drawing sketches, one basic principle can help you to create highly effective diagrams: keep your diagrams at a consistent level of detail. If you’re talking about high-level concepts like the way independent software systems communicate to fulfill a business use case, try not to drop down into lower-level concepts like class or module names that will clutter the diagram. Keeping your diagrams at a consistent level of detail will prevent you from showing too much detail or too little detail, meaning everyone can understand what you are trying to convey. It’s often better to create multiple diagrams each at a different level of detail.

UML is a wonderful language you can use to communicate complex systems in an understandable manner with little or no technical expertise. However it maybe too formal for rapid knowledge-crunching sessions, as the team will need to retry and model many times. Don’t try to use elaborate packages such as Visio or Rational Rose to capture a moving model. Instead, sketch out the model on the whiteboard. You will be less attached to a sketch that took you minutes to draw than a diagram in Visio that took you most of the morning. If you must write up your knowledge-crunching sessions, do it at the end when you know the most about the problem domain.

Class Responsibility Collaboration Cards

Capturing information visually is an effective way to quickly communicate ideas and concepts. However, because DDD is built around the core idea of a shared language, it is important to use knowledge-gathering techniques that focus on creating a concise and powerful language.

CRC (Class Responsibility Collaboration) cards are divided into three areas and contain the following information:

• A class name, which represents a concept in the domain
• The responsibilities of the class
• Classes that are associated and are required to fulfill its purpose

CRC cards focus the team and the business experts on thinking about the language of the concepts in the problem domain.

Defer the Naming of Concepts in Your Model

Naming is important when modeling a domain. However, premature naming can be a problem when you discover through further knowledge crunching that concepts turn out to be different from what you first understood them to be. The issue is the association with the word that was chosen as the original name and the way it shapes your thinking. Greg Young suggests (http://codebetter.com/gregyoung/2012/02/28/the-gibberish-game-4/) making up words for areas of the model you are not sure about, using gibberish. I tend to favor using colors, but the idea is the same. Instead of giving areas or concepts of the model real names, use gibberish until you have understood all the responsibilities, behavior, and data of a concern. Deferring the naming of concepts in your model will go a long way toward helping you avoid modeling a reality that you are trying to change to the business’s benefit.

Also look out for overloaded terms. The types of names that you want to avoid are XXXXService and XXXXManager. If you find yourself appending service or manager to a class or concept, think more creatively, strive for real intent behind a name. When you feel you have really understood a part of the model, you will be in a better place to give it a sensible and meaningful name.

Behavior-Driven Development

Behavior-Driven Development (BDD) is a software development process, based on Test-Driven Development (TDD), which focuses on capturing the behavior of a system and then driving design from the outside in. BDD uses concrete domain scenarios during conversations with domain experts and stakeholders to describe the behaviors of a system.

Much like DDD, BDD does not focus on the technical aspects of an application. Where it differs is that BDD focuses on the software behavior, how the system should behave, whereas DDD focuses on the domain model at the heart of the software that is used to fulfil the behaviors—a small but important distinction.

BDD has its own form of UL to specify requirements—an analysis language, if you will, known as GWT (Given, When, Then). The GWT format helps to structure conversations with domain experts and reveal the real behaviors of a domain.

To demonstrate how BDD is used, look at how the requirements for a product are captured utilizing user stories.

An example of a feature for an e-commerce site:

Feature: Free Delivery for Large Orders

Some stories for this feature may be:

In order to increase the average order total, which is $50,

As the marketing manager

I would like to offer free delivery if customers spend $60.

Another story example for this feature:

In order to target different countries that have different spending habits,

As the marketing manager

I would like to set the qualifying order total threshold for each delivery country.

A feature describes a behavior that gives value to the business. In a feature story, a role and benefit are also included. The clarity of the role that relates to the feature enables the development team, along with domain experts, to understand who to talk to or who to proxy. The benefit justifies the existence of the feature, helping to clarify why the business user wants the feature.

To better understand a feature and its behavior, use BDD scenarios to describe the feature under different use cases. Scenarios start with an initial condition, the Givens. Scenarios then contain one or more events, the Whens, and then describe the expected outcomes, the Thens.

An example of a BDD scenario:

Scenario: Customer satisfies the spend threshold for free delivery

Given: Threshold for free delivery is set at $60

And: I am a customer who has a basket totaling $50

When: I add an item to my basket costing $11

Then: I should be offered free delivery

A further example:

Scenario: Customer does not satisfy the spend threshold for free delivery but triggers message to up sale

Given: Threshold for free delivery is set at $60

And: I am a customer who has a basket totaling $50

When: I add an item to my basket costing $9

Then: I should be told that if I increase my basket goods total by $1.00, I will be offered free delivery

In addition to being a light way of capturing requirements, the scenarios provide acceptance criteria that developers and testers can use to determine when a feature is complete, and business users can use to confirm that the team understands the feature.

Using this method of capturing requirements removes the ambiguity that traditional requirement documentation can result in while also heavily emphasizing the domain language. The features and scenarios are a product of collaboration between the development team and business experts, and can help to shape the UL.

Rapid Prototyping

Favor rapid prototyping during knowledge-crunching sessions. Business users like nothing more than screen mock-ups, because they reveal so much more about the intent they have behind a product. Users understand UI; they can interact with it and act out work flows clearly.

Another form of rapid prototyping is to capture requirements in code. Greg Young calls this code as analysis; he has a presentation on this topic we can access here: http://skillsmatter.com/podcast/open-source-dot-net/mystery-ddd. Again, business users will love the fact that you are writing and creating before their eyes. Starting to code will help focus analysis sessions. Starting to implement abstract ideas from knowledge crunching will enable you to validate and prove your model. It also helps to avoid only abstract thinking, which can lead to analysis paralysis (http://sourcemaking.com/antipatterns/analysis-paralysis).

Coding quickly helps create your powerful questions and helps find missing use cases. Use the code to identify and solve the problems. After an hour or so of talking, see if you can create a code model of your brainstorming. I often find that implementing ideas in code helps to cement domain concepts and prove model designs. This process helps to keep the development team engaged and deeply engrossed in learning about the domain as they can start to get feedback on a design immediately.

Remember: Only create a code model of what is relevant and within the specific context to solve a given problem; you can’t effectively model the entire domain. Think small and model around rules; then build up. Most important, remember that you are writing throw-away code. Don’t stop at the first useful model, and don’t get too attached to your first good idea.

Look at Paper-Based Systems

If you are developing a solution for a problem domain that does not have an existing software solution, look to how the business uses language in the current paper-based solution. Some processes and work flows may not benefit from an elaborate model to handle edge cases. Rare edge-case scenarios may be better solved by handing power back to the manual process; modeling this may result in a lot of effort for little business value.

Understanding Intent

Be wary of customers asking for enhancements to existing software, because they will often give you requirements that are based on the constraints of the current systems rather than what they really desire. Ask yourself how often you have engaged with a user to really find the motivation behind a requirement. Have you understood the why behind the what? Once you share and understand the real needs of a customer, you can often present a better solution. Customers are usually surprised when you engage them like this, quickly followed by the classic line: “Oh, really? I didn’t know you could do that!” Remember: You are the enabler. Don’t blindly follow the user’s requirements. Business users may not be able to write effective features or effectively express goals. You must share and understand the underlying vision and be aware of what the business is trying to achieve so you can create real business value.

Event Storming

Event Storming is a workshop activity that is designed to quickly build an understanding of a problem domain in a fun and engaging way for the business and development teams. Groups of domain experts, the ones with the answers, and development team members, the ones with the questions, work together to build a shared understanding of the problem domain. Knowledge crunching occurs in an open environment that has plenty of space for visual modeling, be that lots of whiteboards or an endless roll of brown paper.

The problem domain is explored by starting with a domain event; i.e., events that occur within the problem domain that the business cares about. A Post-it note representing the domain event is added to the drawing surface and then attention is given to the trigger of that event. An event could be caused by a user action that is captured and added to the surface as a command. An external system or another event could be the originator of the event; these are also added to the canvas. This activity continues until there are no more questions. The team can then start to build a model around the decision points that are made about events and when they, in turn, produce new events.

Event storming is an extremely useful activity for cultivating a UL as each event and command is explicitly named, this goes a long way to producing a shared understating between the developers and business experts. It can also reveal sub domains and the core domain of the problem domain, which will be covered in detail in Chapter 3, “Focusing on the Core Domain.” The biggest benefit however is that it’s fun, engaging, and can be done quickly. Alberto Brandolini created this activity and more information can be found on his blog at http://ziobrando.blogspot.co.uk/.

Impact Mapping

A new technique for better understanding the intent of business stakeholders is impact mapping. With impact mapping, you go beyond a traditional requirements document and instead you try to work out what impacts the business is trying to make. Do they want to increase sales? Is their goal to increase market share? Do they want to enter a new market? Maybe they want to increase engagement to create more loyal customers who have a higher lifetime value.

Once you understand the impact the business is trying to make you can play a more effective role in helping them to achieve it. Significantly for DDD, you will be able to ask better questions during knowledge-crunching sessions since you know what the business wants to achieve.

Surprisingly, impact mapping is a very informal technique. You simply create mind-map-like diagrams that accentuate key business information. You work with the business so that, like knowledge crunching, it is a collaborative exercise that helps to build up a shared vision for the product. Figure 2.3 shows an example impact map demonstrating an e-commerce company’s desired impact of selling 25% more bicycles.

An impact map, rather obviously, starts with the impact. In Figure 2.3, this is to sell 25% more bicycles, as mentioned. Directly connected to the impact are the actors—the people who can contribute to making the desired impact. In Figure 2.3, that would be developers and data scientists. Child nodes of the actors are the ways in which the actors can help. In Figure 2.3, one way the developers can help to create the business impact is to improve the performance of the website so that people are more likely to make a purchase. Finally, the last level of the hierarchy shows the actual tasks that can be carried out. You can see in Figure 2.3 that one way the developers may be able to make the website faster is to remove slow frameworks.

On many software projects the developers only get the lower tiers of an impact map—what the business thinks they need and how they think the developers should achieve it. With an impact map, though, you can unwind their assumptions and find out what they really want to achieve. And then you can use your technical expertise to suggest superior alternatives that they would never have thought of.

Some DDD practitioners rate impact mapping very highly, both when applied with DDD or in isolation. You are highly encouraged to investigate impact mapping by browsing the website (http://www.impactmapping.org/) or picking up a copy of the book: “Impact Mapping,” by Gojko Adzic.

Understanding the Business Model

A business model contains lots of useful domain information and accentuates the fundamental goals of a business. Unfortunately, very few developers take the time to understand the business model of their employers or even to understand what business models really are.

One of the best ways to learn about a company’s business model is to visualize it using a Business Model Canvas; a visualization technique introduced by Alexander Osterwalder and Yves Pigneur in their influential book, “Business Model Generation” highly recommended and very accessible reading for developers. A Business Model Canvas is extremely useful because it breaks down a business model into nine building blocks, as shown in Figure 2.4 which illustrates an example Business Model Canvas for an online sports equipment provider.

Understanding the nine building blocks of a business model tells you what is important to the business. Key information like: how it makes money, what its most important assets are, and crucially its target customers. Each of the sections of a business model is introduced below. For more information, the “Business Model Generation” book is the ideal learning resource.

• Customer Segments—the different types of customers a business targets. Examples include niche markets, mass markets, and business-to-business (b2b).
• Value Propositions—the products or services a business offers to its customers. Examples include physical goods and cloud hosting.
• Channels—how the business delivers its products or services to customers. Examples include physical shipping and a website.
• Customer Relationships—the types of relationships the business has with each customer segment. Examples include direct personal assistance and automated electronic help facilities.
• Revenue Streams—the different ways the business makes money. Examples include advertising revenue and recurring subscription fees.
• Key Resources—a business’s most important assets. Examples include intellectual property and important employees.
• Key Activities—the activities fundamental to making the business work. Examples include developing software and analyzing data.
• Key Partnerships—a list of the business’s most significant partners. Examples include suppliers and consultants.
• Cost Structure—the costs that the business incurs. Examples include salaries, software subscriptions, and inventory.

Armed with the information presented by a Business Model Canvas you will be empowered to ask meaningful questions of domain experts and help to drive the evolution of the business—not just the technical implementation. The small effort of finding and understanding your employer’s business model is well worth it.

Deliberate Discovery

Dan North, the creator of BDD, has published a method for improving domain knowledge called deliberate discovery (http://dannorth.net/2010/08/30/introducing-deliberate-discovery/). Instead of focusing on the framework of agile methodologies during planning and requirement gathering stages, such as the activities of planning poker and story creation, you should devote time to learning about areas of the problem domain that you are ignorant about. Dan states that “Ignorance is the single greatest impediment to throughput.” Therefore a greater amount of domain knowledge will improve your modeling efforts.

At the start of a project teams should make a concerted effort to identify areas of the problem domain that they are most ignorant of to ensure that these are tackled during knowledge-crunching sessions. Teams should use knowledge-crunching sessions to identify the unknown unknowns, the parts of the domain that they have not yet discovered. This should be led by the domain experts and stakeholder who can help the teams focus on areas of importance and not simply crunching the entire problem domain. This will enable teams to identify the gaps in domain knowledge and deal with them in a rapid manner.

Model Exploration Whirlpool

Eric Evans, the creator of Domain-Driven Design, has created a draft document named the Model Exploration Whirlpool (http://domainlanguage.com/ddd/whirlpool/). This document presents a method of modeling and knowledge crunching that can complement other agile methodologies and be called upon at any time of need throughout the lifetime of application development. It is used not as a modeling methodology but rather for when problems are encountered during the creation of a model. Telltale signs such as breakdowns in communication with the business and overly complex solution designs or when there is a complete lack of domain knowledge are catalysts to jump into the process defined in the Model Exploration Whirlpool and crunch domain knowledge.

The whirlpool contains the following activities:

• Scenario Exploring

  A domain expert describes a scenario that the team is worried about or having difficulty with in the problem domain. A scenario is a sequence of steps or processes that is important to the domain expert, is core to the application, and that is within the scope of the project. Once the domain expert has explained the scenario using concrete examples the team understands, the group then maps the scenario, like event storming in a visual manner in an open space.

• Modeling

  At the same time of running through a scenario, the team starts to examine the current model and assesses its usefulness for solving the scenario expressed by the domain expert.

• Challenging the Model

  Once the team has amended the model or created a new model they then challenge it with further scenarios from the domain expert to prove its usefulness.

• Harvesting and Documenting

  Significant scenarios that help demonstrate the model should be captured in documentation. Key scenarios will form the reference scenarios, which will demonstrate how the model solves key problems within the problem domain. Business scenarios will change less often than the model so it is useful to have a collection of important ones as a reference for whenever you are changing the model. However, don’t try and capture every design decision and every model; some ideas should be left at the drawing board.

• Code Probing

  When insight into the problem domain is unlocked and a design breakthrough occurs the technical team should prove it in code to ensure that it can be implemented.