Learn how a context-based approach to software development more closely aligns business needs with software building and implementation.
Join the DZone community and get the full member experience.
Every software project has its own aura. That aura existed before the project was even started. It gave birth to the project and will be alive when the project will be decommissioned and/or replaced with some other project. This aura is The Full Context.
The Full Context consists of all information directly or indirectly related to the project. It’s the single source of truth for every single decision related to the project, from the decision to start it to the name of every variable in the code.
The Full Context is enormously big and contains a lot of business, economic, and political information, such as company finances, the influence of persons or groups on particular decisions, or even the state of the mood of the developer that affected a particular decision.
Dealing with such huge amounts of information is possible only by layering it into a hierarchy of abstractions. Each layer of the hierarchy consists of elements — each element can be considered a word, and the whole set of elements at the same level of abstraction: the language. This language is then used by the next layer of abstraction to express words used by the layer above, and so on and so forth.
In most cases, there is no single “root” abstraction and no single hierarchy of abstractions. Instead, the context information is structured as a bunch of independent hierarchies.
It should be noted that strict layering of abstractions is essential to keep context comprehensible. Abstractions leaking to upper levels may result in uncontrolled growth of complexity and make context an incomprehensible mess.
The hierarchical context structure enables us to extract only the technical part of The Full Context, i.e., the part directly related to the project. Let’s call this part The Limited Context, or simply The Context. This part of the full context is the only one usually necessary for development. To abstract out non-technical aspects, it is convenient to consider The Context as the single source of truth of all made project-related technical decisions. This abstraction removes “why” these decisions were made by removing all non-technical factors. This is a deliberate decision, necessary to limit complexity by keeping only parts essential for software development.
The Context is constantly updated and extended by new technical decisions we make every day. If some decision is not yet part of The Context, the decision is somehow made (usually using procedures specific to a particular team/company/product/etc.) and put into context. These decisions, therefore, look like a “decision map,” which maps each “issue” to a particular “decision” and invokes a predefined procedure if an element is missing.
From general considerations, it makes sense to keep this “decision map” as small as possible because it directly contributes to the complexity of The Context. In other words, it is preferable to have a smaller set of more general/generic decisions that covers a wider range of similar situations.
Let’s take a closer look at The Context and check what else is there. Besides decision map, there are:
The word business here is a placeholder because what is business is up to each particular project and The Full Context which gave it birth. In the blockchain industry, at the top of the abstraction hierarchy, there will be blockchain domain and blockchain processes.
