concept context map in category software development
This is an excerpt from Manning's book Writing Great Specifications: Using Specification by Example and Gherkin.
The concepts we’ll be using to manipulate and comprehend these large domains come from the field of domain-driven design (DDD). This chapter and the next one will rely heavily on ideas borrowed from DDD. You may be familiar with DDD; I first mentioned it in chapter 1 when I talked about ubiquitous languages in specifications. In this chapter, we’ll discuss domains—subdomains, core domains, secondary domains, and generic domains—as well as domain models, a ubiquitous language, glossaries, bounded contexts, and context maps. This chapter is be a high-level summary of the most important concepts of strategic domain-driven design and shows how you can use these techniques in designing your specification suites.
Figure 11.9 shows what a context map looks like in theory. It shows two models, each in its own bounded context. Each model is a visual representation of the domain concepts present in each context as well as the relationships between the concepts. (In practice, such diagrams are most often drawn in UML, a popular modeling language that provides a standard way to visualize the design of a system.) You can also see the translation map, which is a space where you can define the points of contact between different bounded contexts. Each point of contact can specify interactions such as false cognates, duplicate concepts, and any other relation that you deem important.
Figure 11.9. A simple context map that lists translations such as false cognates and duplicate concepts between two theoretical models in their bounded contexts
Figure 11.10 shows a more practical example based on the Activitee platform and the false cognates and duplicate concepts we dealt with in section 11.1. Software development teams often draw maps like this one to outline explicit translations for any communication and highlight any sharing between contexts. The map defines the territory of each context and the borders between contexts. Without a context map, people on other teams may not be aware of contextual bounds and may unknowingly make changes that blur the edges or complicate the interconnections.
Figure 11.10. A simple context map that lists previously defined false cognates and duplicate concepts between Activitee’s bounded contexts
A context map is different than the map I talked about when comparing a specification suite to a map. Due to automation and its link to real working code, a specification suite can only be a model of the bounded contexts in a single codebase. So if you have to split your bounded contexts into separate codebases due to the complexity of the system or your system architecture, each specification suite will be able to map only what it can automate; therefore, it will always be limited to the reach of its testing code. A simple, practical example is that two different subsystems can be written in two different programming languages, which makes unified testing more difficult. You have to resort to non-automated methods, such as context maps. It really is just a simple drawing. Still, each specification suite with a glossary will help you create better context maps because it’s an automated, frequently validated, always up-to-date map of each bounded context. But the context map itself must be maintained manually.
A context map is an entirely new kind of map. If a specification suite is a map of requirements organized according to DDD principles, then a context map is a map of specification suites and the relationships between suites.
Why are context maps important? Splitting the domain model into multiple contexts won’t automatically make the domain model smaller, easier to comprehend, or less complex. It will decentralize complexity.