sebastianpfischer328756Introduction
Architecture patterns are models influencing the full project structure. They are different than design patterns in a sense that design patterns tent to resolve a problem locally. A famous list of design-patterns can be found here.
Here we will list some of the most common architecture pattern (excluding DDD and micro-services pattern).
Layer pattern
Description
The layers architectural pattern helps to structure applications that can be decomposed into groups of subtasks, each of which is at a particular level of abstraction. Each layer provides services to the next higher layer. Services in a layer are implemented using services from the next lower layer.
Benefices
- Clean dependencies (clear view what dependence on what)
- Improve reusability (each layer provide a new abstraction/service, allowing to replace elements in the upper-layers without changing the base.
Issues
- It can be tricky to have the upper-layers behaving as wanted if the under-layer are modified.
Usage strategy
- Embedded devices because need of HW abstractions, etc...
Client-server pattern
Description
In the Client-server architectural pattern, a server component provides services to multiple client components. A client component requests services from the server component. Servers are permanently active, listening for clients. The requests are sent beyond process and machine boundaries.
Benefices
- Centralize services per servers, enforce strong cohesion.
- Each server can be considered as a standalone application, and its behaviour is independent of external influences besides the network itself.
- Different teams can work on different topics with no need to interact to each other.
- Applicable for network services
Issues
- Enforce clients to adapt to the server messaging pattern and adapt themselves to it.
Usage strategy
- Domain with multiple players, where many need the same kind of information.
Master-slave pattern
Description
The Master-slave pattern supports fault tolerance and parallel computation. The master component distributes the work among identical slave components, and computes a final result from the results the slaves return.
Benefices
- Scalability the application per design
- Fault tolerance
- Divide & conquer principle
Issues
- Slaves are isolated, they cannot share states between themselves
- Latency between the master & slaves not controllable
Usage strategy
- Domain more oriented towards tooling. Need of specific requests/commands/executions are needed to scale (Hadoop, Spark, Jenkins, kubernets)
Pipe-filter pattern
Description
The Pipe-filter architectural pattern provides a structure for systems that produce a stream of data. Each processing step is encapsulated in a filter component. Data is passed through pipes. The pipes may be used for buffering or for synchronization.
Benefices
- Work on data-streams
- Agnostic of the data-stream generator.
- Reusability & extendibility of the filters (to add & remove steps in the process)
- Filters can be developed stand-alone
- Behaviour is the combination of the different filters working on the data-stream
Issues
- Data-transformation overhead
Usage strategy
- Gateways, data-analytics... (ex: Luigi, airflow, kafka)
Broker pattern
Description
The Broker pattern is used to structure distributed systems with decoupled components, which interact by remote service invocations. Such systems are very inflexible when components have to know each others’ location and other details. A broker component is responsible for the coordination of communication among components: it forwards requests and transmits results and exceptions.
Servers publish their capabilities (services and characteristics) to a broker. Clients request a service from the broker, and the broker then redirects the client to a suitable service from its registry.
Benefices
- Dynamic changes, additions, deletions and relocations of objects possible
- One source of communication with/to. The broker define its interface
- tbd
Issues
- Central component, needs to be robust & fast to work on the requests
Usage strategy
- Connection of two worlds that does not really understand each other but need to interact to each other... (MQTT)
Peer-to-peer pattern
Description
The Peer-to-peer pattern can be seen as a symmetric Client-server pattern: peers may function both as a client, requesting services from other peers, and as a server, providing services to other peers. A peer may act as a client or as a server or as both, and it may change its role dynamically.
Benefices
- More oriented micro-service pattern. Each "node" is a stand-alone, getting requests and interacting with other nodes
- Self-organization approach
Issues
- No guarantee of quality of service
- Security difficult to guarantee at some extend: if not a trusted space
Usage strategy
- Never really handle requests, but also need to ask other nodes requests that needs to be handle by them.
Model-view-controller pattern
Description
In the Model-View-Controller pattern, or MVC pattern (see Figure 3.13), an interactive application is divided into three parts: the model contains the core functionality and data, the view displays the information to the user (more than one view may be defined), and the controller handles the input from the user.
Benefices
- For GUI, model does not depend on the number of views
- Views can be easily modified without changing anything else
Issues
- High complexity in the implementation to have a clear separation of concerns between each MVC elements. Existing frameworks should be used here.
- Synchronization issues between the different MVC constantly needed, even if nothing is happening.
Usage strategy
- GUI, websites...
Blackboard pattern
Description
The Blackboard pattern is useful for problems for which no deterministic solution strategies are known. Several specialized subsystems assemble their knowledge to build a possibly partial or approximate solution. All components have access to a shared data store, the blackboard. Components may produce new data objects that are added to the blackboard. Components look for particular kinds of data on the blackboard, and may find these by pattern matching.
Benefices
- New application easy to add
- Adding new data is easy
Issues
- Modifying data in the blackboard very difficult. May influence all applications added
- Big computing power needed (scale with the number of data contained in the board)
Usage strategy
- More useful when you have pipes filling a big database (ex: no-sql database like cassandra) and you need to extract and work on some data.
- More applicable for application that needs a lot of data to perform. Such as deep-learning, etc...