This lesson was originally featured at Software Architectural Patterns & Design Structures. It has been republished here with permission from Nishant Sharma.

Architectural Patterns

• Layered pattern: When the uses relation among software elements is strictly unidirectional, a system of layers emerges. A layer is a coherent set of related functionality. In a strictly layered structure, a layer can only use the services of the layer immediately below it.

• Shared-data (or repository) pattern: This pattern comprises components and connectors that create, store, and access persistent data. The repository usually takes the form of a (commercial) database. The connectors are protocols for managing the data, such as SQL.

• Microkernel :The microkernel pattern, or plug-in pattern, is useful when your application has a core set of responsibilities and a collection of interchangeable parts on the side. The microkernel will provide the entry point and the general flow of the application, without really knowing what the different plug-ins are doing.

• Client-server pattern: The components are the clients and the servers, and the connectors are protocols and messages they share among each other to carry out the system's work.

• Multi-tier pattern: which describes how to distribute and allocate the components of a system in distinct subsets of hardware and software, connected by some communication medium. This pattern specializes the generic deployment (software-to-hardware allocation) structure.

• Microservices: When you write your application as a set of microservices, you're actually writing multiple applications that will work together. Each microservice has its own distinct responsibility and teams can develop them independently of other microservices. The only dependency between them is the communication. As microservices communicate with each other, you will have to make sure messages sent between them remain backwards-compatible. This requires some coordination, especially when different teams are responsible for different microservices.

A diagram can explain.

Architects design structures

1. Module structures embody decisions as to how the system is to be structured as a set of code or data units that have to be constructed or procured.

2. Component-and-connector structures embody decisions as to how the system is to be structured as a set of elements that have runtime behavior (components) and interactions (connectors).

3. Allocation structures embody decisions as to how the system will relate to non software structures in its environment (such as CPUs, file systems, networks, development teams, etc.).

Some Useful Module Structures

- Decomposition structure: The units are modules that are related to each other by the is-a submodule-of relation, showing how modules are decomposed into smaller modules recursively until the modules are small enough to be easily understood.

- Uses structure: In this important but overlooked structure, the units here are also modules, perhaps classes. The units are related by the uses relation, a specialized form of dependency.

- Layer structure: The modules in this structure are called layers. A layer is an abstract "virtual machine" that provides a cohesive set of services through a managed interface.

- Class (or generalization) structure: The module units in this structure are called classes. The relation is inherits from or is an instance of

- Data model: The data model describes the static information structure in tenns of data entities and their relationships.

Some Useful C&C Structures

- Service structure: The units here are services that interoperate with each other by service coordination mechanisms such as SOAP

- Concurrency structure: This component-and-connector structure allows the architect to determine opportunities for parallelism and the locations where resource contention may occur.

Some Useful Allocation Structures

- Deployment structure: The deployment structure shows how software is assigned to hardware processing and communication elements.

- Implementation structure: This structure shows how software elements (usually modules) are mapped to the file structure( s) in the system's development, integration, or configuration control environments.

- Work assignment structure: This structure assigns responsibility for implementing and integrating the 1nodules to the teams who will carry it out.

Software design vs Software architecture

Architecture in a Project Life-Cycle Context

1. Waterfall

2. Iterative

3. Agile

4. Model-driven development

SOAP

SOAP is a protocol specification for XML-based information that distributed applications can use to exchange information and hence interoperate. It is most often accompanied by a set of SOA middleware interoperability standards and compliant implementations, referred to (collectively) as WS. SOAP and WS together define many standards, including the following:

• An infrastructure for service composition. SOAP can employ the Business Process Execution Language (BPEL) as a way to let developers express business processes that are implemented as WS * services.

• Transactions. There are several web-service standards for ensuring that transactions are properly managed: WS-AT, WS-BA, WS-CAF, and WS-Transaction.

• Service discovery. The Universal Description, Discovery and Integration (UDDI) language enables business.

• Reliability. SOAP, by itself, does not ensure reliable message delivery. Applications that require such guarantees must use services compliant with SOAP's reliability standard: WS-Reliability.

One Pager Cheat Sheet

• This lesson provides an overview of key software architectural patterns and design structures, which has been republished with permission from Nishant Sharma.
• This article summarizes six Architectural Patterns, including the Layered pattern, Shared-data (or repository) pattern, Microkernel, Client-server pattern, Multi-tier pattern and Microservices, to explain how components and connectors create and access persistent data.
• Architects design module, component-and-connector, and allocation structures.
• The module structures useful for breaking down a program's design include Decomposition, Uses, Layer, Class, and Data Model structures.
• The Service structure enables interoperability through service coordination mechanisms like SOAP, while the Concurrency structure provides opportunities for parallelism and helps identify contention points.
• The Deployment structure maps software to hardware, the Implementation structure assigns modules to a file structure, and the Work assignment structure assigns teams responsibility for implementing and integrating the modules.
• Software architecture is the high-level design of a software system, while software design is more focused on implementation details.
• The key approaches to consider when talking about Architecture in a Project Life-Cycle Context are Waterfall, Iterative, Agile, and Model-driven development.
• SOAP and its associated WS* standards provide an infrastructure for service composition, transactions, service discovery, and reliability for distributed applications.