Architectural Pattern

Category

An architectural pattern describes a reusable solution to a recurring problem in software architecture.

Patterns

Blackboard

Architectural Pattern

The Blackboard pattern shows how a complex problem, such as image or speech recognition can be broken up into smaller, specialized subsystems that work together to solve a problem.

Broker

Architectural Pattern

The Broker pattern hides the implementation details of remote service invocation by encapsulating them into a layer other than the business component itself.

Broker Revisited

Architectural Pattern

The Broker Revisited pattern connects clients with remote objects by mediating invocations from clients to remote objects while encapsulating the details of network communication.

Command and Query Responsibility Segregation (CQRS)

Architectural Pattern

Command and Query Responsibility Segregation uses the same definition of Commands and Queries and maintains the viewpoint that they should be pure. The fundamental difference is that in CQRS objects are split into two objects, one containing the Commands one containing the Queries.

Command Processor

Architectural Pattern

Separates the request for a service from its execution. A command processor component manages requests as separate objects, schedules their execution, and provides additional services such as the storing of request objects for later undo.

Event Sourcing

Architectural Pattern

Use an append-only store to record the full series of events that describe actions taken on data in a domain, rather than storing just the current state, so that the store can be used to materialize the domain objects.

Interceptor

Architectural Pattern

The intercepting filter design pattern is used when we want to do some pre-processing / post-processing with request or response of the application. Filters are defined and applied on the request before passing the request to actual target application.

Layers

Architectural Pattern

The Layered architectural pattern helps to structure applications that can be decomposed into groups of subtasks in which each group of subtasks Is at a particular level of abstraction.

Microkernel

Architectural Pattern

The Microkernel architectural pattern applies to software systems that must be able to adapt to changing system requirements. It separates a minimal functional core from extended functionality and customer-specific parts. The microkernel also serves as a socket for plugging in these extensions and coordinating their collaboration.

Model-View-Controller (MVC)

Architectural Pattern

The MVC pattern separates the domain models (model), the presentation (view), and the actions based on external input (controller) into three separate classes.

Model-View-ViewModel (MVVM)

Architectural Pattern

The MVVM pattern separates the presentation logic (view) from its abstract representation (view model). The view model provides access to the model data and operations which operate on models.

Pipes and Filters

Architectural Pattern

The Pipes and Filters architectural pattern provides a structure for systems that process a stream of data. Each processing step is encapsulated in a filter component. Data [are] passed through pipes between adjacent filters. Recombining filters allows you to build families of related filters.

Presentation-Abstraction-Control

Architectural Pattern

The PAC architectural pattern defines a structure for interactive software systems in the form of a hierarchy of cooperating agents. Every agent is responsible for a specific aspect of the application's functionality and consists of three components: presentation, abstraction, and control.

Publish/Subscribe (pub/sub)

Architectural Pattern

Publish/Subscribe is a messaging pattern where a publisher sends messages to a channel without the knowledge of who is going to receive them. It is the responsibility of the channel to deliver a copy of the messages to each subscriber.

Reflection

Architectural Pattern

The Reflection architectural pattern provides a mechanism for changing structure and behavior of software systems dynamically. It supports the modification of fundamental aspects, such as type structures and function call mechanisms. In this pattern, an application is split into two parts. A meta level provides information about selected system properties and makes the software self-aware. A base level includes the application logic. Its implementation builds on the meta level. Changes to information kept in the meta level affect subsequent base-level behavior.

Repository

Architectural Pattern

A Repository mediates between the domain and data mapping layers, acting like an in-memory domain object collection. Client objects construct query specifications declaratively and submit them to Repository for satisfaction. Objects can be added to and removed from the Repository, as they can from a simple collection of objects, and the mapping code encapsulated by the Repository will carry out the appropriate operations behind the scenes.

View Handler

Architectural Pattern

The View Handler design pattern helps to manage all views that a software system provides. A view handler component allows clients to open, manipulate and dispose of views. It also coordinates dependencies between views and organises their update.