Domain Storytelling means that we let domain experts tell us stories about their tasks. While listening, we record the stories using a pictographic language. The domain experts can see immediately whether we understand their story correctly. After very few stories, we are able to talk about the people, tasks, tools, work objects, and events in that domain.
This book is an in-depth guide on how to use Domain Storytelling. It provides the means to use and adapt Domain Storytelling for different purposes, for example: * Crunch domain knowledge: Use Domain Storytelling to bring together domain experts from different departments, cross department boundaries and challenge assumptions. Work your way down from big-picture overviews to in-depth domain analysis. * Find good boundaries for your software: Domain Stories help to break down a domain into manageable slices. These are useful for splitting a monolith into modules, for designing microservices, and finding context boundaries in Domain-driven Design. * Domain Stories help you to determine which classes and methods you need to express your domain knowledge in code. * Derive requirements from Domain Stories to bridge the gap between domain knowledge and software development. * Support organizational change by making transparent how a new software system will change the way how people work.
Domain Storytelling is one of the least known yet extremely powerful techniques for understanding and mapping domain interactions in the professional work environment. Henning and Stefan are the same people who created the technique by perfecting some existing methodologies for modeling and designing software.
The book is very well organized, the chapters flow naturally keeping the reader super engaged and always wanting to advance to next topic, the example domains are well chosen and help the reader with getting a good taste of how to apply the concepts and techniques learned in practice. To me, this book stands out by adding an incredibly useful skill to the engineer, architect or requirements analyst, which is enabling a deep comprehension of the problem space, the understanding of hidden nuances in current processes of most domains is usually not something that can easily be obtained with other discovery tools and techniques.
This book is a must for anyone working on a complex domain.
Henning and Stefan describe a very practical and fun-to-use way of talking with domain experts in order to explore a business domain. The iconographic language helps communicate on an additional level to the face to face conversation that is needed to record domain stories. The descriptions in this book are directly applicable, the additional tips and tricks shared in their own little stories and episodes throughout the book help to understand what to look out for.
To achieve DDD, you must extract domain model using some methodology. Domain Storytelling is a promising one for this purpose. It enables actors, work objects and activities to be captured much more efficiently in the context of real world domain stories told by domain experts. Domain Storytelling can be used in conjunction with other methodologies like Use Cases, User Story Mapping or Event Storming. The book clearly explains all these topics very well. Authors have solid experience in many projects and the book seems to be the reflection of that experience; it is an easy-to-read and very enlightening book.
For anybody with some architecture background it’s just too wordy. The insight to page ratio is quite low. I’d pay the same for half of the pages or even quarter. The technique itself is great and I’m happy to read about it. It’s how the book is written that I dislike.
The book might make sense as the very first encounter with modern architecture. But for that the topic is too niche and new at least today. I wouldn’t recommend it to newbies, there are books that cover fundamentals better.
A simple way to describe domains and stories about it. Should be very applicable in workshops with engineering teams and business customers.
A good composition of common practices around requirements engineering, system thinking, and software modeling prior explored by other authors.
Good to see references to UML and BPML. I see the need to have auxiliary diagrams to express clear state changes which is a common task during customer workshops. OPN comparison is not explored, however I would recommend to system level modeling.
I missed a specific support for problem modeling, the use of “coarse-grained, Pure, As-Is” is not prescriptive. I would suggest Problem-Based SRS approach on this case in exchange with domain storytelling design.
I really like the idea and need to give it a try in a dummy project. The format itself is really understandable and once you are accustomed to it just a quick glance is enough to get the gist. I also like to create requirements or rather acceptance tests and bounded contexts directly from these sentences.
I really like every format that gets people back to a table and starts a good discussion, either to get the same understanding of a problem or just to ease communication.
If the first part explaining Domain Storytelling was a bit more condensed it would have been better.
For the rest of the book, if you have read Event Storming by Alberto Brandolini, and you have experience or are familiar with Domain-Driven Design, ubiquitous language, bounded contexts, etc... there will be nothing new or interesting.
Domain Storytelling by examples introduces the reader to the world of collaborative modeling. The first part of the book is practical. Having the first chapter finished, a reader may reason how it works and understands the basics. Further pages drill the topic down through the pictographic language, modeling scope, workshop preparation, and comparison with other modeling techniques. I appreciate tips and tricks for running the workshop smoothly and effectively. Although some of them are obvious, the majority are signs of experience. The latter part tries to briefly explain the usage of the technique to find bounded contexts and subdomains, remodel existing processes, find requirements, and promote organizational changes. It states about benefits apart from knowledge crunching. Unfortunately, it is not as deep as the first part and uses quite simple examples. Authors make a feeling that strategic DDD is an easy task. Naive readers may fall into the trap and underestimate the challenge. On the other hand, experienced readers will not find it helpful either. To Sum up, it is a decent introduction to another modeling technique worth having in your toolbox. It is definitely too long. I believe the authors could compress it by one-third. It is worth reading, though, skipping the second part.
What I liked: - Easy-to-follow process on how to use domain storytelling - Great recommendations for analog and digital approaches - Relatable examples and stories to showcase how to use it - Clear examples on why not to approach it in certain manners
What I didn't like: - Got the printed copy and the pages were thin. Sometimes the diagrams and words from the previous page could be seen just enough that it was distracting.
If there's a digital-only version of this, I would rate this 5 stars for content. I am looking forward to adding Domain Storytelling to the practices I employ with my clients and projects.
A great book to explain - what Domain Storytelling is - how to apply it in different domains - why use particular elements of this technique in different scenarios
At the same time, the second part of this book (about modeling / bounded contexts / organization changes / buy vs build) is too short to understand concepts. You won't get any insights if you are already familiar (even briefly) with the topic.
Knowledge Level: Intermediate Audience: Whoever wants to learn about domain storytelling and fans about visual diagramming. Review: The author reviews a way to have visual help on domain designs, however, this helps not just to have technical and process diagrams. Lessons Learned: Domain Storytelling structure and syntaxis, how to use it.