Architectural Style:-

An architectural style, sometimes called an architectural pattern, is a set of principles—a coarse grained pattern that provides an abstract framework for a family of systems. An architectural style improves partitioning and promotes design reuse by providing solutions to frequently recurring problems.

Types of Architectural Styles are:-

1) Client/Server Architectural Style:-

The client/server architectural style describes distributed systems that involve a separate client and server system, and a connecting network. The simplest form of client/server system involves a server application that is accessed directly by multiple clients, referred to as a 2-Tier architectural style.

Other variations on the client/server style include:

Client-Queue-Client systems. This approach allows clients to communicate with other clients through a server-based queue. Clients can read data from and send data to a server that acts simply as a queue to store the data.

Peer-to-Peer (P2P) applications. Developed from the Client-Queue-Client style, the P2P style allows the client and server to swap their roles in order to distribute and synchronize files and information across multiple clients.

The main benefits of the client/server architectural style are:

Higher security. All data is stored on the server, which generally offers a greater control of security than client machines.

Centralized data access. Because data is stored only on the server, access and updates to the data are far easier to administer than in other architectural styles.

2) Component-Based Architectural Style

Component-based architecture describes a software engineering approach to system design and development. It focuses on the decomposition of the design into individual functional or logical components that expose well-defined communication interfaces containing methods, events, and properties.

The key principle of the component-based style is the use of components that are:

Reusable. Components are usually designed to be reused in different scenarios in different applications. However, some components may be designed for a specific task.

Replaceable. Components may be readily substituted with other similar components.

Not context specific. Components are designed to operate in different environments and contexts. Specific information, such as state data, should be passed to the component instead of being included in or accessed by the component.

Extensible. A component can be extended from existing components to provide new behavior.

Domain Driven Design Architectural Style

3) Domain Driven Design (DDD) is an object-oriented approach to designing software based on the business domain, its elements and behaviors, and the relationships between them. It aims to enable software systems that are a realization of the underlying business domain by defining a domain model expressed in the language of business domain experts. The domain model can be viewed as a framework from which solutions can then be rationalized.

The following are the main benefits of the Domain Driven Design style:

Communication. All parties within a development team can use the domain model and the entities it defines to communicate business knowledge and requirements using a common business domain language, without requiring technical jargon.

Extensible. The domain model is often modular and flexible, making it easy to update and extend as conditions and requirements change.

Testable. The domain model objects are loosely coupled and cohesive, allowing them to be more easily tested.

4) Layered Architectural Style

Layered architecture focuses on the grouping of related functionality within an application into distinct layers that are stacked vertically on top of each other. Functionality within each layer is related by a common role or responsibility. Communication between layers is explicit and loosely coupled. Layering your application appropriately helps to support a strong separation of concerns that, in turn, supports flexibility and maintainability.

Common principles for designs that use the layered architectural style include:

Abstraction. Layered architecture abstracts the view of the system as whole while providing enough detail to understand the roles and responsibilities of individual layers and the relationship between them.

Encapsulation. No assumptions need to be made about data types, methods and properties, or implementation during design, as these features are not exposed at layer boundaries.

Reusable. Lower layers have no dependencies on higher layers, potentially allowing them to be reusable in other scenarios.

Loose coupling. Communication between layers is based on abstraction and events to provide loose coupling between layers.

5) Message Bus Architectural Style

Message bus architecture describes the principle of using a software system that can receive and send messages using one or more communication channels, so that applications can interact without needing to know specific details about each other. It is a style for designing applications where interaction between applications is accomplished by passing messages (usually asynchronously) over a common bus.

A message bus provides the ability to handle:

Message-oriented communications. All communication between applications is based on messages that use known schemas.

Complex processing logic. Complex operations can be executed by combining a set of smaller operations, each of which supports specific tasks, as part of a multistep itinerary.

Modifications to processing logic. Because interaction with the bus is based on common schemas and commands, you can insert or remove applications on the bus to change the logic that is used to process messages.