Glossary of Terms
The purpose of this glossary is to ensure that the source code and the underlying documentation found on GitHub for Possum Labs YouTube tutorials are accessible and understandable. Prior to implementing Possum Labs solutions, we recommend that all viewers briefly review this glossary of terms to ensure clarity of meaning and usage in the context of Possum Labs solutions.
Possum Labs builds upon and develops with open source code. Our work relies upon relevant terminology; however, Possum Labs recognizes that domain-specific language may vary in particular to contexts. Furthermore, we acknowledge that the audience for our tutorials includes business analysts and other decision makers for whom we wish to make the language used as accessible as possible.
Most terms are derived from Domain-Driven Design: Tackling Complexity in the Heart of Software by Eric Evans. It is recommended reading for developers, but when it comes to testing there is usually a much narrower set of concerns and options.
Using DSL to Create Meaningful Tests
The goal is to test an existing system, which we will consider to be our Bounded Context. From this context, we develop a DSL (Domain Specific Language) as our Ubiquitous Language. We will then take the names from the Bounded Context. We will use Model-Driven Design to provide a structure to this DSL by expressing Entities and access them through Repositories. We consider the interface (UI, API, Database, ESB) we interact with for these tests our Context Map, and we will insulate our tests using Anti-corruption Layer.
The Bounded Context defines and bounds the particular system that we will test. In enterprise systems, it is often necessary to break large systems up into specific distinct contexts, because a single solution will not elegantly fit the whole system. It is the parts that we test, vs the parts we consider services and systems we depend upon.
Identifying the different interfaces that we will use to test the application and clarifying which systems or subsystems we will not be working with for this context. This delineation may include a range of range applications from UI (user interface), API (application program interface), ESB (enterprise service bus) to DB (database).
Domain Specific Language (DSL)
A particular vocabulary tailored with consideration for the Bounded Context in which we intend to test an existing system. These are the terms that describe the business within which the application lives.
In Model-Driven Design, the code and model remain tightly related with the function of keeping the code meaningful. We keep the model very literal to the business at hand so that it is easier to understand.
As the name implies, the anti-corruption layer is a form of protection or insulation that protects our activities from corruption from other aspects of the application(s) within which we work. Over time various aspects of most applications will change, in particular, most applications will evolve and are refactored. In testing, we likely have little influence over the core application, so instead, we must focus on insulating our work or bounded context from those changes by building a layer between us and the application under test. This focus means that if the application changes, we have to make fewer (if any) changes for the tests to change with it.