Preface
Misunderstandings between software developers and people from the business departments are a common problem. Bad communication is a plague that makes projects fail. Domain Storytelling is a remedy because this technique transforms domain knowledge into effective business software. Domain Storytelling brings together domain experts, software developers, user experience designers, product owners, product managers, and business analysts on the same page. They learn from each other by telling stories and drawing them as easy-to-understand pictures.
Who Should Read This Book
The book is aimed at everyone involved or interested in software development, including nontechnical readers. There are only a few code examples, and, generally speaking, no prior knowledge is required. Where it makes sense, we will point you to some recommended reading.
Beyond software development professionals, the book is also relevant to CxOs, vice presidents, directors, team leads from business departments, and domain experts. They can use the book to improve their understanding of their business processes and to improve communication with their IT counterparts.
This Book in the Software Development Landscape
This book is meant to be a practical guide. We wanted to keep it concise, although we were tempted to write a book on Domain-Driven Design, domain modeling, requirements, agile, and software development in general. All of these topics are relevant to Domain Storytelling and are referenced in this book, but we tried not to dive too deep into topics that other authors have already addressed brilliantly. If you are curious, here is an (incomplete) list of authors who have influenced us:
• Heinz Züllighoven et al.: The Tools and Material Approach [Züllighoven 2004] is important for how we look at software development. It promotes user-centric software development and is built around the powerful metaphors tool and material. The book was first published in the late 1990s and covers topics such as iterative-incremental development, modeling, scenarios, and patterns for software construction.
• Eric Evans: Domain-Driven Design (DDD) [Evans 2004] shares many characteristics with the Tools and Material Approach, although the two were developed independently from each other. The concepts bounded context and ubiquitous language immediately resonated with us. DDD opened a new area of application for Domain Storytelling, influencing the direction in which we have been pushing the method in the last couple of years.
• Kent Beck et al.: The Agile Manifesto [Beck et al. 2001] put “individuals and interactions over processes and tools,” and “working software over comprehensive documentation.” Domain Storytelling is about individuals and their interactions on two levels: (1) domain stories show people and their collaboration, and (2) the workshop in which these stories are told brings together humans to interact with each other. Extreme Programming (XP) brought the concept of stories into software development and introduced user stories to the agile world [Beck 1999, Beck/Andres 2004, and Cohn 2004].
• Alistair Cockburn: Writing Effective Use Cases [Cockburn 2001] is one of our favorite books on requirements. Even if you do not apply use cases, the book is worth a read. It shows how to follow an agile path from domain to software. We borrowed the idea of goal levels and applied it to Domain Storytelling.
• Gojko Adzic: Specification by Example [Adzic 2011] highlights the importance of conversations in software development. We started to view software development as a series of conversations about the domain and requirements, supported by several “conversation methods” like Domain Storytelling. We share Adzic’s views on requirements and the benefits of using examples.
• Christiane Floyd: We had the pleasure of learning from Professor Floyd at the University of Hamburg. She researched and taught (among other things) modeling theory, the limits of modeling, sociotechnical aspects of modeling and software development, and participatory design. She published papers in German and English. If you are curious, see for example “Software Development as Reality Construction” [Floyd 1992] and search for papers on her STEPS approach, an early example of what later became known as agile software development.
What This Book Covers
This book is divided into two parts: Part I explains the method, and Part II describes how to use and adapt it for specific purposes.
Part I, “Domain Storytelling Explained”: Contains everything you need to know to use Domain Storytelling for learning about a domain.
Chapter 1, “Introduction”: Explains what Domain Storytelling actually is. Also, we introduce a case study that will give you a first impression of the method and show you why it is useful.
Chapter 2, “The Pictographic Language”: Explains the graphical notation. To record domain stories visually, you need a set of symbols and rules for combining them. This chapter will also show you what we consider good language style and what pitfalls to avoid. If you have never tried Domain Storytelling, you should do so after finishing Chapter 2. Get out a piece of paper and a pen, and model a workflow that you are familiar with. However, before trying Domain Storytelling in a workshop situation, you should continue reading the rest of Part I.
Chapter 3, “Scenario-Based Modeling”: Introduces you to one of the major differences between domain stories and other business process modeling languages: Every domain story is about one case. You will learn which cases you should model and how to keep an overview.
Chapter 4, “Scope”: Is about the level of detail that stories have, whether they are descriptive or exploratory, and the amount of technical information they contain. You will need to consider all these factors every time you start a new domain story. This chapter will help you to choose the right scope.
Chapter 5, “Modeling Tools”: Summarizes our experience with different modeling tools. We recommend which tools are useful in which situations, describe their strengths and weaknesses, and give practical tips that will help you model more effortlessly.
Chapter 6, “The Workshop Format”: Shows that Domain Storytelling works best when used for collaborative modeling. You will learn how to a prepare, conduct, and follow up on a workshop. This chapter will help you to become a good moderator.
Chapter 7, “Relationship to Other Modeling Methods”: Discusses other modeling methods and workshop formats and how to combine Domain Storytelling with them. This chapter will help you to pick the right tool for the right job.
Part II, “Purposes”: Deals with the different problems and purposes for which Domain Storytelling can be used. Even though we use the same example in all chapters of Part II, you do not have to read the chapters in order. Just pick the purposes that you are interested in.
Chapter 8, “Case Study—Alphorn Auto Leasing Inc.”: This chapter introduces a second, more comprehensive case study.
Chapter 9, “Learning Domain Language”: Speaking the language of the domain experts is the key for effective conversations about business processes and software requirements. This chapter is for you if you are new to a domain, if the software that you work on does not use real terms from the domain and you want to change that, or if you work in an organization where no real domain language exists and you want one to emerge.
Chapter 10, “Finding Boundaries”: Many domains are too big to be understood and modeled as a whole. You need to break down a domain into manageable units. Read this chapter if you are struggling with a monolith and want to reorganize it or split it into more manageable parts, if you want to design microservices, or if you want to apply Domain-Driven Design and have difficulties identifying bounded contexts. The chapter will also help if your development team has become too big to work efficiently or if you already have more than one development team and want to find out how you can organize the work for these teams.
Chapter 11, “Working with Requirements”: How do you bridge the gap between domain knowledge and requirements? We show you how to derive requirements from domain stories so that you can discuss priorities and viable products. This chapter is for you if you consider yourself a product owner, product manager, business analyst, requirements engineer, or developer in a cross-functional team that does its own requirements analysis.
Chapter 12, “Modeling in Code”: If your ultimate goal is to develop software, then, at some point, you need to move from modeling with diagrams and sticky notes to modeling in programming languages. This chapter will show you how to transition from visual modeling to code.
Chapter 13, “Supporting Organizational Change”: The goal of a new software system usually is to make work easier, faster, and more efficient (in short: better). This goal will not be reached by digitalizing bad manual processes. Neither will a pile of requirements magically turn into a seamless business workflow. To build good business software, you need to go beyond merely modeling the current situation. You will need to design the future way of working. Domain stories help to do this and visualize how new software will change the way people work. Read this chapter if you want to optimize business processes, roll out new software, or discuss and promote change in business processes.
Chapter 14, “Deciding Make or Buy and Choosing Off-the-Shelf Software”: Not every piece of software is custom-built. Many domains are supported by off-the-shelf software. Domain stories can help to decide if a new software system should be developed or bought. If the decision is to buy an existing solution, usually several vendors will offer their products. Here too, domain stories can be useful in making a decision.
Chapter 15, “Finding Shadow IT”: When you are trying to consolidate software application landscapes or promote digitalization, shadow IT stands in your way. Every company beyond a certain size uses software that the central IT department is not aware of. All those little solutions that run in business departments and that hardly anyone knows about are often business-critical. Domain experts use shadow IT unconsciously, so it is easily overlooked. Domain stories can help IT and management find this shadow IT and see the whole IT landscape.
Conventions
When we define a new term, we set it in bold, e.g., actor. Terms that were defined by other authors are set in italics when we use them for the first time, e.g., bounded context. Scope factors appear in small caps, e.g., COARSE-GRAINED. Words from case studies are surrounded by quotation marks, like “moviegoer.” Code is set in constant width, like the class MovieTicket.
Important notes are marked with a lightbulb icon: <lightbulb icon>. When we give concrete advice, our tips are marked with a checkmark icon: <checkmark icon>.
We provide examples in the form of case studies and “stories from trenches.” Appearances of case study Alphorn Auto Leasing Inc. are indicated with a car icon: <automobile icon>. The stories from the trenches are marked with a sunflower icon: <sunflower icon>.
Legend for “Opening Stories”
As modelers, we couldn’t resist the temptation to describe Domain Storytelling itself with domain stories. That’s why several chapters of this book begin with an “opening story”—a short domain story that explains what the chapter is about. The legend in Table P.1 will help you to interpret the icons that we use in those stories.
Table P.1 Icons used in “Opening Stories”
Supplementary Materials
On www.domainstorytelling.org/book, we created a companion website for this book [DomainStorytelling BookWebsite]. It contains the example domain stories that we show in this book. The examples were created with Egon.io, an open-source modeling tool that our company WPS – Workplace Solutions created [Egon.io Website]. You can import the source files from this book into Egon.io and “replay” the domain stories (instructions are on the website).
The companion website also contains the bibliography of this book, with clickable links to online resources.
Furthermore, on www.domainstorytelling.org, you will find links to useful materials, including a collection of videos and articles [DomainStorytelling Website].
About the Cover
The cover pictures of the books in Vaughn Vernon’s Signature Series use an organic theme. We were happy about this because domain stories develop in an organic way, too. Like the sunflowers you see on the cover, a domain story starts from a small seed, grows, and if everything goes well, eventually blooms into a beautiful blossom. The relationship of domain and domain story is similar to the one between sun and sunflower:
• A sunflower can’t exist without sun. Likewise, a domain story will dry up without contact to the domain.
• The sunflower looks like the sun. Likewise, the domain story is formed to resemble the domain.
• During the day, the sunflower turns its head to follow the sun. Likewise, the domain story follows the domain.
• A sunflower often lives in a field together with many other sunflowers. Likewise, a domain story usually doesn’t come alone but together with other stories.
All these properties make the sunflower not only a splendid cover picture plant but also a friendly-looking symbol for Domain Storytelling.
With that out of the way, welcome to The Sunflower Book. We wish you happy reading and happy modeling!