Architecture Repository/Enabling strategic product goals with architecture patterns/Architecture patterns

From mediawiki.org
Jump to navigation Jump to search

An architectural pattern is a general, reusable approach to a commonly occurring problem in software architecture within a given context. The patterns in the sections below enable the system to be flexible, reusable, and to answer modern technological needs so that we can achieve our strategic goals.

Loose coupling[edit]

Loose coupling is the practice of organizing a system into independent, distinct subsystems that communicate with one another to support the complete operation of the system. The implementation of how to split the operation of the system into subsystems depends on the needs of the system, the capabilities it requires, the infrastructure, and the way product and technology teams work together.

Product benefits[edit]

  • Clear domains: Each subsystem can be replaced or swapped with another easily and without disruption to the rest of the system.
  • Quicker turnaround: The independence of the individual subsystems means that as long as the event structure remains clear, adding or changing behavior is easier and requires less dependence on other teams or groups that manage other subsystems.
  • More product flexibility: Instead of relying on a single monolithic output that includes all possible views or interfaces, the system can have multiple independent subsystems, each responsible for a separate dedicated purpose.

Related to[edit]

  • While loose coupling dictates the action of separating the system into subsystems, the event-based interactions pattern defines how the subsystems communicate with one another.
  • A decoupled frontend is an example of loose coupling that relates specifically to the separation between the system behavior and the interface.

Event-based interactions[edit]

The event-based interactions pattern defines the way that subsystems interact with each other in a loosely coupled system. Instead of querying a central database, separate subsystems exchange information publishing and consuming “events”. Each event contains information about a change that has occurred, regardless of where the change originated. These events can be consumed by the rest of the system, allowing each subsystem to remain distinct and encapsulated but still share, subscribe, and respond to operations done by other subsystems.

Product benefits[edit]

  • Clear domains: Each subsystem can be replaced or swapped with another easily and without disruption to the rest of the system.
  • Quicker turnaround: The independence of the individual subsystems means that as long as the event structure remains clear, adding or changing behavior is easier and requires less dependence on other teams or groups that manage other subsystems.
  • Preprocessed data: The ability to respond to events as they happen means products can process data asynchronously, constructing powerful, customized outputs to return to users on demand.

Related to[edit]

  • While loose coupling dictates the action of separating the system into subsystems, the event-based interactions pattern defines how the subsystems communicate with one another.

Canonical data model[edit]

A canonical data model is a predictably-structured, technology-agnostic data structure that represents the system as a whole instead of each component having its own representation of the data. Discrete bits of information are interconnected based on relationships between them and contextualized with metadata. This allows users and machines to consume content easily without specifically caring about the underlying technologies driving the system.

Product benefits[edit]

  • Structured content: Having an agreed-upon, standardized, technology-agnostic data structure enables the universal structuring of the content across our different products.
  • Interconnectedness: Each structured data piece includes information about how it relates to other pieces (for example, by keywords, by hierarchy, etc). This enables finding and utilizing context-related links between pieces of information to produce powerful product outputs.

Related to[edit]

  • Knowledge as a service: This strategic initiative transforms knowledge created as a single web page into discrete units of predictably structured information that are interrelated.
  • Federated API: Defines a unified, consistent response to all API queries regardless of the module or product it requests, while allowing individual subsystems to evolve and change independently.