--- title: "Glossary" created: 2026-07-02 updated: 2026-07-02 type: source-page status: imported namespace: software-architecture-metapatterns source_repository: https://github.com/denyspoltorak/metapatterns source_wiki: https://github.com/denyspoltorak/metapatterns/wiki source_path: "Appendices/Glossary.md" source_url: https://github.com/denyspoltorak/metapatterns/wiki/Appendices/Glossary source_license_note: "See namespace README; preserve attribution and source links." --- # Glossary > Imported source page from Denys Poltorak's *Architectural Metapatterns* wiki. Source path: `Appendices/Glossary.md`. *Abstractness* – the scope of information that a *concept* operates. Highly abstract *concepts* describe the *system’s* behavior in less words. *Action* – an act of a *system* that changes its environment. [[wiki/concepts/source/basic-metapatterns/layers|*API*]] (*application programming interface*) – a set of *methods* or *messages* that a *component* exposes to its *clients*. [[wiki/concepts/source/basic-metapatterns/layers|*Application*]] – the most *abstract* layer that usually *integrates components* of a less *abstract* layer. *Architectural pattern* – a way to structure a *system* or a part of a *system* to achieve desirable properties (address a set of *forces*). *Architectural style* – see *architecture*. *Architecture* – the structure (*components* and their *interactions*) of a system which follows a certain framework or guidelines. *ASS diagram* – a *structural diagram* with *abstraction*, *subdomain* and *sharding* for coordinates. *Asynchronous communication* – the mode of *communication* when the sender of the *request message* does not stop the execution of its *scenario* to wait for the confirmation message. *Attack surface* – the amount of *components* and functionality that faces an external network (potentially exposed to hackers). *Availability* – the percentage of time that the *system* is operational (satisfies its *users*). *Bounded context* – a subset of *requirements* and code that shares a set of *concepts*. Usually consists of internals of a *component* and *APIs* of all the *components* it uses. *Business logic* – the thing that *users* pay for. It is the heart of the business and is usually the largest part of the *project*. You cannot buy *business logic*, only *implement* it. *Business logic* comprises *use cases* and *business rules*. *Business rules* – *domain concepts* and their relations. They make the low-level half of *business logic*. *Choreography* – a kind of *workflow* in which *components* that belong to the same level of *abstractness* cooperate to implement a *use case*. *Client* – an external *component* or *system* that makes use of a *component* or *system* in question. *Cohesion* – the density of logical connections between entities inside a *component*. *Colocated* – running in the same address space (process) on the same hardware. *Communication* – transfer of data or signals in a *system*. *Complexity* – the cognitive load caused by the quantity of entities (*concepts* or *modules*) and their relations that a programmer needs to operate. *Component* – an encapsulated part of a *system*. It exposes an *API* to the system's *clients* and/or other *components* of the *system*. *Concept* – a notion of an element of a *system's* behavior, usually present in *requirements*. *Contract* – the informal rules for the behavior of a *component* expected by its *clients*. *Control* – a kind of system that supervises physical entities or external programs. *Coupling* – the density of logical connections between *components*. *Cross-cutting concern* – a functionality that should be present in multiple *components*. *Data store* – anything where data can be placed or retrieved. Includes *databases*, file systems, and cloud storage. *Database* – a service for storing, retrieving, and analyzing data. *Debugging* – trying to force the *system* to behave correctly from the user’s point of view. *Deployment* – uploading a *component* to the hardware that will execute it. *Design* – planning for the best way to write code. *Design* – see *architecture*. *Design space* – the multitude of possible ways to *design* a given project. *Development* – building a *project* for its *users*. Usually involves intermixed *design*, *implementation*, *debugging* and *testing* phases. *Distributed* – spread over multiple computers that *communicate* via a network. *Domain* – the whole of knowledge (including *requirements*) that is needed to build a *system*. [[wiki/concepts/source/basic-metapatterns/layers|*Domain*]] – the middle layer of a *system* that contains its *business rules*. *Event* – a signal that carries some meaning for a *system* or *component*. *Events* may carry data. *Fault tolerance* – the ability of a *system* to remain (at least partially) operational if one or more of its *components* fail (become inaccessible due to a hang, crash or a hardware failure). *Forces* – restrictions on the design and development of a system based on the *qualities* it should meet (see *non-functional requirements*) and organizational limitations (such as time, budget and skills). *Functional requirements* – the *requirements* that describe *inputs* and *outputs* of a *system*, but not its *performance* or stability. *Global use case* – a *use case* that involves most of the *components* of a *system*. Such *scenarios* are strongly affected by the *system’s* structure. *Implementation* – the process of writing code. *Implementation* – internals of a *component*. *Infrastructure* – the lowest layer of a *system* that provides general-purpose functionality (tools) to its upper layers. *Input* – *events* or data that a *system* reacts to. *Integration* – see *orchestration*. *Integration complexity* – the *complexity* of understanding how individual *components interact* to make a *system*. *Interactions* – the kinds and routes of *communication* between *components* of a *system*. *Interface* – see *API*. *Latency* – the delay between a *system’s* receiving *input* and producing a corresponding *output*. *Layers* – *components* of a *system* partitioned by the level of *abstraction*. *Messaging* – communication by sending short pieces of data. *Method call* – invocation of an *interface* method (or procedure) of a *component* by another *component*. *Metapattern* – a cluster of *patterns* that have similar *topologies* and address related issues. *Module* – a *colocated* (in-process) *component*. *Non-functional requirements* (*NFR*s) – expected properties of a *system* (such as its stability or response time) which are crucial for the *system* to be built, *deployed*, and used successfully. Closely related to *qualities* and *forces*. *Notification* – an *event* that one *component* sends to another *component*(s) to inform them of some change. *Operational complexity* – see *integration complexity*. *Orchestration* – a kind of *workflow* where a single dedicated *component* (*Orchestrator*) makes use of (usually multiple) less *abstract components*. *Facade* \[[wiki/concepts/source/appendices/books-referenced|[GoF]]\] is a good example. *Output* – *actions* or data that a *system* produces. *Pattern* – a documented approach (blueprint) for solving a recurrent programming issue. *Pattern Language* – a set of interrelated *patterns* intended to cover most aspects of *designing systems* in a target *domain*. *Performance* – a measure of a *system*’s *throughput*, *latency* and *resource* consumption. *Persistent data* – data which survives rebooting the software. *Pipeline* – a set of *components* for stepwise *processing* of data. *Processing* – transformation of *input* data into *output* data. *Project* – the process of making a *system*. *Pub/sub (publish/subscribe)* – a mode of *communication* when one *component* (*subscriber*) receives a subset of *notifications* from another *component* (*publisher*). It is the *subscriber* that chooses which *notifications* it is interested in. *Qualities* – the properties which a *component* or (sub)*system* manifests to satisfy *forces*. *Real-time* – a *force* that requires the *system* to respond to incoming *events* immediately. *Request/confirmation* – a pair of *messages* between two *components* (Requestor and Executor). The *request* describes an *action* that the requestor wants the executor to run (R =\> E). The *confirmation* describes the results of the execution (R \<= E). *Requirements* – a set of rules that describe the correct (expected) behavior of the *system*. *Resources* – CPU, memory, network bandwidth and other stuff that costs money. *Scaling* – ability to increase *throughput* of a system by providing it with more *resources*. *Scenario* – see *use case*. *Service* – a *distributed component*. *Services* – *components* of a *system* partitioned by *subdomain*. *Sharding* – deploying multiple instances of a *component*. *Single point of failure* – a software or hardware *component* which if fails makes the entire *system* non-operational. High-*availability systems* should avoid *single points of failure*. [[wiki/concepts/source/basic-metapatterns/layers|*SPI*]] (*service provider interface*) – a set of *methods* or *messages* that a *component* expects to be supported by the *components* it uses. *State* – data that a *component* keeps between processing its *inputs*. *Structural diagram* – a graphical representation of the structure of a (sub-)*system* that shows *components* and their *interactions*. *Stub* – a very simple *implementation* of a *module* that allows other *components* that use it to run without starting the original *module*. *Stubs* are used to *implement modules* concurrently or *test* them in isolation. *Subdomain* – a distinct *cohesive* part of *domain* knowledge. *Synchronous communication* – the mode of communication when the *requesting component* waits for results of its *request* to another *component* before continuing to run its *task*. *System* – a self-sufficient set of *communicating components* that were brought together or *implemented* to satisfy its *users* (by running *use cases*). *Task* – a high-level sequence of execution steps. Similar to *use case* or *scenario*. *Team* – a few programmers and testers that work on a *component*. Teams of more than 5 members lose productivity to communication overhead. *Testing* – checking how satisfactorily the *system* behaves. *Throughput* – the amount of data a *system* can *process* per unit of time. *Topology* – A map of system components and their relations, similar to a *structural diagram*. *Use case* – a behavior expected by *system*’s users. A *system* is *implemented* to run *use cases*. *Use cases* are the high-level half of *business logic*. *User* – a human that uses a *system* and usually pays well if satisfied with its behavior. *Vendor lock-in* – a pitfall when a *system* relies on an external provider so much that it is impossible to change the provider. It is similar to falling prey to a monopoly. *Workflow* – a sequence of actions (*messages* or *method calls*) required to *implement* a *use case*.