| Domain Storytelling (Pearson) |
|
Author: Stefan Hofer This book sets out to be a practical guide to database domains, bringing together domain experts, software developers, designers and business analysts to describe just what domain storytelling is and what it can do for you. The book starts by explaining what domain storytelling is, and how to use it for learning about a domain. The book's subtitle "A collaborative, visual and agile way to build domain-driven software' is a good short description, and the authors essentially build on this title. The opening part looks at the graphical notations used in domain storytelling, which is the main thing that domain storytelling relies on, along with a structured scenario-based approach. 
If you've not encountered domain storytelling before, it's a way of capturing knowledge about a data domain and converting that knowledge into business software that can make use of the data and the domain. It's a collaborative modeling technique that looks at how people work together on the data. Having looked in detail at the pictographic language, the next few chapters in part one cover scenario-based modeling, modeling tools, and the 'scope' of a domain story. This chapter describes the way a domain story can differ in terms of granularity, whether you're looking at the domain as it is at the moment or the way it will be in the future, and whether you're including existing software or starting from a theoretical basis. Modeling methods, specifically modeling workshops where interested people thrash out the specifics of the domain story, are the topic of the next chapter, and the opening part of the book ends with a look at how domain modeling relates to other modeling methods such as event storming, user story mapping, and example mappling. Part two of the book looks at how to use and adapt domain storytelling for different purposes, starting with a case study that is then used to illustrate later chapters. This is followed by a chapter on how to learn domain language that describes the difficulties you may encounter. There's a good chapter on 'finding boundaries' that explains how to recognize that you are working with too large a domain and how to split it into more manageable units. It sounded good in theory; whether it would work in real life is difficult to assess. The next chapter looks at identifying the requirements for what the software should do, and like the previous chapter, reads well but all developers know how tricky this is in practice. A chapter titled 'modeling in code' comes next, looking at how to move from abstract models to actual code. This is followed by a look at how to deal with organizational change, where your carefully constructed model has to change to meet business changes. A look at how to choose between buying or creating business software comes next. The final chapter looks at 'finding shadow IT', where the authors suggest ways to discover the smaller business systems that the IT department knows nothing about but that are actually critical to the running of the business. The book then closes with a 'conclusions' chpater and appendices. Overall, this book reads well, and sounds very plausible. I haven't used the techniques described in it for real, which would be the only true measure of how useful it is, but it rang plenty of bells from past situations. A useful book. To be informed about new articles on I Programmer, sign up for our weekly newsletter, subscribe to the RSS feed and follow us on Twitter, Facebook or Linkedin.
|
|||
| Last Updated ( Tuesday, 08 March 2022 ) |